사설 IP로의 HTTPS: 인증서 신원인가 호스트 이름인가

https://10.60.0.25 의 서비스는 DNS 이름이 없어도 인증된 TLS를 사용할 수 있습니다. 주소가 클라이언트가 검증해야 할 신원이며, 인증서는 이를 정확히 기술해야 합니다. 결정할 것은 그 주소가 신원으로 쓰일 만큼 안정적인지, 아니면 호스트 이름이 유지하기 더 쉬운지입니다. VPN은 도달 가능성에 답할 뿐 이 질문에는 답하지 않습니다.

신원과 신뢰를 바로잡으면 IP 기반 URL은 정당한 설계입니다.

클라이언트가 실제로 검증하는 것

클라이언트는 URL의 참조 신원을 인증서의 주체 대체 이름과 대조합니다. IP 주소의 경우 주소와 같은 iPAddress 항목을 뜻합니다. 친숙한 일반 이름은 그 대체물이 아닙니다.

RFC 9525 는 IP 주소 신원을 DNS 이름과 분리하고 일치 규칙을 정의합니다. 주소를 주체 레이블에만 두거나 DNS 유형 항목으로 두면 일치가 생기지 않습니다. 그래서 경고가 나타날 때 점검할 필드가 SAN입니다.

신뢰는 두 번째의 독립적인 점검입니다. 이름 일치는 신뢰할 수 없는 체인, 만료된 인증서 또는 다른 목적으로 발급된 인증서를 고치지 못합니다.

첫 번째 결정: 주소가 신원으로 쓰일 만큼 안정적인가

주소가 배포 수명 내내 고정되어 있다면 IP SAN 인증서는 단순하고 정직합니다. 서비스가 이동할 수 있다면 이동할 때마다 인증서 교체와 조정된 클라이언트 업데이트가 필요합니다.

안정적인 호스트 이름은 그 결합을 줄입니다. 클라이언트는 이름을 사용하고, 승인된 DNS가 이를 현재 주소에 매핑하며, 주소 변경은 더 이상 신원 변경이 아닙니다. 인증서는 여전히 갱신이 필요하지만 URL은 바뀌지 않습니다.

관리되는 hosts 파일 항목은 작은 환경에서 매핑을 제공할 수 있습니다. 배포 책임이 늘어나지만 TLS 검증을 대체하지는 않습니다.

두 번째 결정: 클라이언트가 발급자를 어떻게 신뢰할지

사설 CA의 경우 승인된 메커니즘으로 신뢰 앵커를 대상 장치에 배포하십시오. 사용자에게 경고를 넘기거나 로그인 페이지가 건네는 인증서를 설치하도록 길들이지 마십시오. 공개적으로 신뢰받는 인증서를 원한다면 계획하기 전에 사설 주소에 대한 발급자의 현재 규칙을 확인하십시오. 대부분의 공개 발급자는 사설 IP를 공개 신원으로 검증하지 않습니다.

실제 브라우저나 애플리케이션을 검토하십시오. 그 신뢰 저장소와 검증 동작은 운영체제의 일반 인증서 문서보다 중요합니다. 콘솔에서만이 아니라 실제 장치에서 확인하십시오.

VPN 게이트웨이가 웹 애플리케이션을 실행하는 기계가 아닐 수 있습니다, 따라서 터널의 인증서가 이것과 관련이 있다고 가정하지 마십시오.

주소 변경이 일어나기 전에 계획하십시오

10.60.0.25 가 10.60.0.40 이 되면 이전 인증서는 더 이상 URL을 기술하지 않습니다. 교체와 클라이언트 업데이트를 함께 계획하고, 이전 중에 검증을 절대 비활성화하지 마십시오.

사용자가 입력하거나 애플리케이션이 설정할 신원을 고르고, 그 주위로 발급, 신뢰, 배포, 갱신을 정렬하십시오. 경고를 닫은 채 도달 가능한 페이지는 클라이언트가 신원을 검증하는 서비스와 같은 결과가 아닙니다.