VPN 전용 사이트의 인증서: DNS-01인가 사설 CA인가

VPN으로만 접근하는 사이트가 인증서를 어떻게 받아야 하는지는 공개 DNS 영역을 통제하는지, 호스트 이름이 공개 로그에 나타나도 되는지, 모든 클라이언트에 사설 신뢰 앵커를 줄 수 있는지, 이 세 가지 조건이 결정합니다. 공개 경로와 사설 경로는 둘 다 작동하는 자물쇠를 만들고 서로 다른 질문에 답합니다. 이 조건을 정하지 않고 하나를 고르는 것이 바로 원하지 않던 공개 인증서를 갖게 되거나 절반의 클라이언트가 거부하는 내부 인증서를 갖게 되는 방식입니다.

인증서는 이름을 증명하고, VPN과 내부 DNS가 경로를 제공합니다.

신뢰받는 이름으로 가는 두 경로

DNS-01 검증을 쓰는 공개 발급자는 통제하는 영역의 TXT 레코드로 이름에 대한 통제를 증명하므로, 웹 서비스가 공개 HTTP 연결을 받아들일 필요가 없습니다. 사설 CA는 내부 이름용 리프 인증서를 발급하고 기기 관리로 신뢰 앵커를 배포하므로, 어떤 공개 로그도 그 이름을 알지 못합니다. 둘 다 정당하며 선택은 편의가 아니라 그 세 조건에서 나옵니다. 어느 경로도 클라이언트에 필요한 경로나 리졸버 항목을 제공하지 않습니다.

공개 인증서는 호스트 이름을 인증서 투명성 로그에도 공개합니다. 이름 자체가 민감하다면 그 공개는 나중에 발견할 부작용이 아니라 설계 결정입니다.

서비스를 노출하지 않는 DNS-01

챌린지 레코드는 영역의 예약된 접두사 아래에 있는 TXT 항목이며, 발급자는 권한 DNS에서 이를 읽습니다. 그 레코드를 만들고 지울 수 있는 ACME 클라이언트와 DNS 통합을 고르고, 갱신 권한은 영역에 대한 범위가 제한된 API 자격 증명이나 검증에만 쓰는 통제된 호스트로 좁게 부여하십시오. 인증서 하나를 갱신하려고 애플리케이션 서버에 제한 없는 등록기관 자격 증명을 주는 것은 작업에 필요한 권한을 훨씬 넘습니다. 여러 주문이 한 이름을 공유하면 TXT 값을 서로 다르게 유지해, 하나를 정리할 때 다른 하나가 아직 필요한 값을 지우지 않게 하십시오.

고정 대기 대신 권한 서버에 대한 확인으로 전파를 기다리십시오. 전파 동작은 공급자마다 다르며, 오늘 통하는 대기는 내일에 대한 증거가 아닙니다.

관리되는 클라이언트와 의도적으로 사설인 이름

관리 대상 기기와 의도적으로 사설인 이름은 내부 CA에 잘 맞습니다. 기기 관리로 신뢰 발급자를 배포한 다음, 의도한 이름에 리프 인증서를 발급하십시오. 운영체제에 한 번 가져오는 것이 모든 브라우저와 애플리케이션에 대한 보편적 주장은 아니므로, 각 클라이언트가 실제로 어느 저장소를 쓰는지 확인하십시오. 리프 고정은 명시적으로 지원되는 곳에서 또 다른 선택지이며, 리프가 바뀔 때마다 신뢰를 한 번 더 갱신하는 비용이 따릅니다.

배포 채널은 키만큼 중요하며, 아무도 설치하지 않는 루트는 아무것도 보호하지 못합니다.

갱신은 설계의 일부입니다

어떤 경로를 택하든 갱신에는 담당자와 절차가 필요합니다. 검증 증명을 새로 고치고, 새 자료를 설치하고, 지원되는 방식으로 리스너를 다시 불러오는 것은 서로 다른 세 단계이며, 대부분의 ACME 클라이언트가 자동화하는 것은 첫 단계뿐입니다. 올바르게 갱신되지만 결코 적재되지 않는 인증서는 만료된 인증서와 같은 장애를 냅니다.

인증서는 VPN 경로를 설치하지 않고 내부 DNS 레코드도 만들지 않습니다. 클라이언트에는 여전히 이름을 사설 주소로 매핑하는 리졸버와 거기에 도달할 경로가 필요합니다. 둘 다 갖춘 클라이언트에서 이름으로 사이트를 시험하십시오.

발급자, 검증 방법, 신뢰 배포 채널, 다시 불러오는 방식을 기록하십시오. 그 네 가지가 갱신 계획입니다.