HTTPS를 통해 사용자가 지정한 호스트에 액세스하는 애플리케이션은 FQDN을 조회하여 지원을 제공해야 합니까?

HTTPS를 통해 사용자가 지정한 호스트의 애플리케이션에 액세스하는 것은 일반적인 요구 사항이지만 실제 애플리케이션에서는 약간의 혼란이 발생할 수 있습니다. 이 문제에 대해 PHP 편집자 Banana는 FQDN을 검색하여 도움을 주어야 한다고 생각합니다. FQDN(정규화된 도메인 이름)은 호스트 이름과 도메인 이름을 포함하는 정규화된 도메인 이름입니다. FQDN을 조회하면 사용자가 지정한 호스트의 정확한 위치를 확인할 수 있어 정확한 도움과 서비스를 제공할 수 있습니다. 따라서 FQDN을 조회하는 것은 HTTPS 액세스 시 유용한 전략입니다.

질문 내용

다른 호스트에서 HTTPS를 통해 서버와 통신하는 golang 애플리케이션을 사용하고 있습니다. 특히 컨텍스트가 중요한 경우: 동일한 Google Cloud 프로젝트의 GCE 인스턴스에서 Dataproc 클러스터와 통신합니다(특별한 도메인 설정이 필요하지 않음).

서버는 클라이언트에 수동으로 설치한 자체 서명 인증서를 생성합니다.

서버와 클라이언트 모두 내 Google Cloud 프로젝트의 GCE 인스턴스입니다(FQDN은 <hostname>.c.<project_id>.internal입니다)

golang의 http.Client를 사용하여 클라이언트에서 서버에 연결하려고 하면 다음과 같은 오류가 발생합니다.

으아악

하지만 FQDN(<server_hostname>.c.<project_id>.internal)을 전달하면 즉시 작동합니다.

참고로 이 동작은 cURL을 실행할 때 나타나는 동작과 일치합니다.

으아악

제 질문은:

1. 짧은/부분 호스트 이름에서는 왜 작동하지 않나요? 같은 도메인에 있으므로 *.c.<project_id>.internal의 일부이고 기본적으로 작동합니다. 그렇죠? 아니면 전달된 문자열을 실제로 와일드카드 문자열과 일치시키는 데 사용해야 합니까(즉, 조회를 수행하지 않고 fqdn을 전달한 경우에만 작동함을 의미함)?
2. 배포용 앱을 구축할 때 모범 사례는 무엇입니까? 짧은 이름을 자체 서명된 인증서와 함께 사용할 가능성이 높은 긴 이름으로 변환할 수 있도록 FQDN을 계산하도록 하는 논리를 추가해야 할까요? 아니면 호출자가 암호 오류를 파악하도록 남겨 두어야 할까요? 메시지? 리>

참고: 유효성 검사를 건너뛰고 싶지는 않습니다. 단지 현재 상황을 더 잘 이해하고 모범 사례가 무엇인지 알고 싶을 뿐입니다.

감사합니다!

솔루션

1. 인증서는 포함된 이름을 기반으로 도메인/호스트와 일치하므로 <server_hostname> 및 <server_hostname> 和 <server_hostname>.c.<project_id>.internal가 동일한 콘텐츠로 확인되더라도 인증서에는 두 번째 인증서(또는 와일드카드)만 포함됩니다. 성냥). 자체 생성된 이름이므로 짧은 이름을 SAN(주체 대체 이름)으로 추가할 수 있습니다. OpenSSL용 추가 플래그:

으아악

공용 CA는 공개적으로 확인할 수 없는 SAN이 포함된 인증서를 제공하지 않을 것입니다. (일부 가능성이 있지만 시도하지 않았습니다)

예를 들어 google.com.someevildomain.org 提供或信任 google.com부터 시작하고 싶지 않다면 이는 보안 기능입니다.

1. 상황에 따라 다릅니다. 인증서를 제어할 수 있는 경우 사용하려는 이름을 추가하기만 하면 됩니다. 이는 결국 많은 SAN이 포함된 단일 인증서가 될 수 있으며, 이 경우 모든 사람이 FQDN을 사용하여 대화하도록 하는 것이 더 깔끔할 수 있습니다. 많은 인증서를 가져올 수 있는 경우 각 서비스에 FQDN 및 짧은 이름이 포함된 자체 인증서를 갖는 것이 좋습니다.

위 내용은 HTTPS를 통해 사용자가 지정한 호스트에 액세스하는 애플리케이션은 FQDN을 조회하여 지원을 제공해야 합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!