SSL-CN (일반 이름)과 SAN (주체 대체 이름)은 어떻게 함께 작동합니까?

SSL-CN (일반 이름)과 SAN (주체 대체 이름)은 어떻게 함께 작동합니까?

---

SSL 인증서의 SAN (주체 대체 이름) 속성에 두 개의 DNS 이름이 포함되어 있다고 가정합니다.

1. domain.tld
2. host.domain.tld

그러나 공통 이름 (CN)은 둘 중 하나로 만 설정됩니다 CN=domain.tld.

• 이 설정에 특별한 의미가 있습니까, 아니면 두 CN을 설정하는 것에 대한 [단점]이 있습니까?
• 다른 하나 host.domain.tld가 요청 되면 서버 측에서는 어떻게됩니까 ?

편집하다:

최근 Eugene의 답변으로 구현에 따라 동작이 다르다는 것을 알게 되었으므로 좀 더 구체적으로 알고 싶습니다. OpenSSL 0.9.8b + 는 주어진 시나리오를 어떻게 처리합니까?

---

이는 구현에 따라 다르지만 일반적인 규칙은 모든 SAN 및 일반 이름에 대해 도메인을 확인하는 것입니다. 도메인이 여기에 있으면 인증서가 연결에 문제가없는 것입니다.

RFC 5280 , 섹션 4.1.2.6에는 "주체 이름이 주제 필드 및 / 또는 subjectAltName 확장에 포함될 수 있습니다"라고 말합니다. 즉, 인증서의 SubjectAltName 확장 및 Subject 속성 (즉, 공통 이름 매개 변수)에 대해 도메인 이름을 확인해야합니다. 이 두 장소는 서로를 보완하고 복제하지 않습니다. SubjectAltName은 www .domain.com 또는 www2 .domain.com 과 같은 추가 이름을 입력하기에 적합한 위치입니다.

업데이트 : '2011 년에 게시 된 RFC 6125 에 따라 유효성 검사기는 먼저 SAN을 확인해야하며 SAN이있는 경우 CN을 확인하지 않아야합니다. RFC 6125는 비교적 최신 버전이며 CN의 "주"도메인 이름과 SAN의 대체 도메인 이름을 포함하는 인증서를 발급하는 인증서와 CA가 여전히 존재합니다. 즉, SAN이있는 경우 유효성 검사에서 CN을 제외하면 다른 유효한 인증서를 거부 할 수 있습니다.

---

절대적으로 정확하려면 모든 이름을 SAN 필드에 입력해야합니다.

CN 필드는 도메인 이름이 아닌 주체 이름을 포함해야하지만 Netscape가이 SSL을 발견했을 때 가장 큰 시장을 정의하지 못했습니다. 서버 URL에 대해 정의 된 인증서 필드가 없습니다.

이것은 도메인을 CN 필드에 넣도록 해결되었으며 현재 CN 필드의 사용은 더 이상 사용되지 않지만 여전히 널리 사용됩니다. CN은 하나의 도메인 이름 만 보유 할 수 있습니다.

이에 대한 일반적인 규칙 : CN-여기에 기본 URL (호환성을 위해)을 넣으십시오. SAN-모든 도메인을 여기에 넣으십시오. CN이 올바른 위치에 있지 않지만이를 위해 사용되기 때문에 CN을 반복하십시오.

올바른 구현을 찾은 경우 질문에 대한 답변은 다음과 같습니다.

• 이 설정에 특별한 의미가 있습니까, 아니면 두 CN을 설정하는 것에 대한 [단점]이 있습니까? CN은 하나의 이름 만 보유 할 수 있으므로 두 CN을 모두 설정할 수 없습니다. 하나의 CN + SAN 인증서 대신 2 개의 간단한 CN 인증서로 만들 수 있지만이를 위해서는 2 개의 IP 주소가 필요합니다.

• 다른 하나 인 host.domain.tld가 요청되면 서버 측에서는 어떻게됩니까? 서버 측에서 일어나는 일은 중요하지 않습니다.

간단히 말해서, 브라우저 클라이언트가이 서버에 연결되면 브라우저는 서버의 공개 키로 암호화 된 암호화 된 패키지를 보냅니다. 서버는 패키지를 복호화하고 서버가 복호화 할 수 있으면 서버용으로 암호화 된 것입니다.

서버는 암호 해독 전에 클라이언트로부터 아무것도 알지 못합니다. 연결을 통해 IP 주소 만 암호화되지 않기 때문입니다. 이것이 2 개의 인증서에 2 개의 IP가 필요한 이유입니다. (SNI는 잊어 버리세요. 아직 XP가 너무 많습니다.)

클라이언트 측에서 브라우저는 CN을 가져온 다음 모든 항목이 확인 될 때까지 SAN을 가져옵니다. 이름 중 하나가 사이트와 일치하면 브라우저에서 URL 확인을 수행 한 것입니다. (인증서 확인에 대해 이야기하는 것이 아닙니다. 물론 많은 ocsp, crl, aia 요청 및 답변이 매번 인터넷으로 이동합니다.)

---

CABForum 기준 요건

아직 기준 요구 사항 섹션에 대해 언급 한 사람이 없습니다. 나는 그들이 중요하다고 생각합니다.

Q : SSL-CN (일반 이름)과 SAN (주체 대체 이름)은 어떻게 함께 작동합니까?
A : 전혀 그렇지 않습니다. SAN이있는 경우 CN을 무시할 수 있습니다. -적어도 검사를 수행하는 소프트웨어가 CABForum의 기본 요구 사항을 매우 엄격하게 준수하는 경우.

(따라서 귀하의 질문에 "수정"에 대한 답변을 드릴 수 없습니다. 원래 질문 만 해당됩니다.)

CABForum 기준 요구 사항, v. 1.2.5 (2015 년 4 월 2 일 기준), 9-10 페이지 :

9.2.2 주체 고유 이름 필드
a. 주체 공통 이름 필드
인증서 필드 : subject : commonName (OID 2.5.4.3)
필수 / 선택 사항 : 더 이상 사용되지 않음 ( 디스코 어링 되었지만 금지되지는 않음)
내용 :있는 경우이 필드에는 단일 IP 주소 또는 하나 인 정규화 된 도메인 이름이 포함되어야합니다. 인증서의 subjectAltName 확장에 포함 된 값 (섹션 9.2.1 참조).

편집 : @Bruno의 댓글 링크

RFC 2818 : HTTP Over TLS , 2000, 섹션 3.1 : 서버 ID :

dNSName 유형의 subjectAltName 확장이있는 경우 해당 확장을 ID로 사용해야합니다. 그렇지 않으면 인증서의 제목 필드에있는 (가장 구체적인) 일반 이름 필드를 사용해야합니다. 일반 이름의 사용은 기존 관행이지만 더 이상 사용되지 않으며 인증 기관은 대신 dNSName을 사용하는 것이 좋습니다.

RFC 6125 : TLS (Transport Layer Security) 컨텍스트에서 X.509 (PKIX) 인증서를 사용하는 인터넷 공개 키 인프라 내에서 도메인 기반 애플리케이션 서비스 ID의 표현 및 확인 , 2011, 섹션 6.4.4 : 일반 이름 확인 :

[...] 제시된 식별자가 DNS-ID, SRV-ID, URI-ID 또는 클라이언트가 지원하는 애플리케이션 특정 식별자 유형을 포함하지 않는 경우에만 클라이언트는 최후의 수단으로 확인할 수 있습니다. 제목 필드 (예 : CN-ID)의 일반 이름 필드에있는 정규화 된 DNS 도메인 이름과 형식이 일치하는 문자열.

참고 URL : https://stackoverflow.com/questions/5935369/ssl-how-do-common-names-cn-and-subject-alternative-names-san-work-together