☰

와일드카드 자체 서명 인증서에서 URL 불일치가 발생하는 이유는 무엇입니까?

tag-icon • tag-icon apache-2.4 openssl self-signed-certificate
와일드카드 자체 서명 인증서에서 URL 불일치가 발생하는 이유는 무엇입니까?

Apache에서 사용할 자체 서명된 와일드카드 인증서를 설정하려고 합니다. 일반적으로 이는 매우 간단합니다. 루트 도메인으로 주체 대체 이름을 설정하고 일반 이름 필드에 *.dcrdev.com을 지정하기만 하면 됩니다. 그러나 이것이 작동하지 않는 것 같습니다. Chrome에서 사이트에 액세스하려고 시도하거나 sslabs에서 테스트할 때 www.dcrdev.com 또는 subdomain1.dcrdev.com과 같은 하위 도메인에 액세스할 때 URL 불일치가 보고됩니다. 왜 그런지 잘 모르겠습니다. Chrome에서 인증서 정보를 볼 때 일반 이름이 *.dcrdev.com으로 표시됩니다.

내 CSR:

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=GB, ST=South Yorkshire, L=Sheffield, O=DCR Holdings, OU=DCR Development, CN=*.dcrdev.com/[email protected]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                lah blah

내 인증서:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1048577 (0x100001)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=GB, ST=South Yorkshire, L=Sheffield, O=DCR Holdings, OU=DCR Root Authority, CN=*.dcrdev.com/[email protected]
        Validity
            Not Before: Oct 13 23:41:03 2015 GMT
            Not After : Oct 10 23:41:03 2025 GMT
        Subject: C=GB, ST=South Yorkshire, L=Sheffield, O=DCR Holdings, OU=DCR Development, CN=*.dcrdev.com/[email protected]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
               Blah blah
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                83:2D:84:F1:E2:B0:72:30:E6:3B:6A:F6:8E:6A:68:8E:3F:D4:69:44
            X509v3 Authority Key Identifier: 
                keyid:F5:A6:82:E2:DD:52:10:CE:FD:C5:C7:E1:E9:CF:C6:8C:30:26:D7:DC

            X509v3 Subject Alternative Name: 
                DNS:dcrdev.com
            X509v3 Key Usage: 
                Digital Signature, Non Repudiation, Key Encipherment
    Signature Algorithm: sha256WithRSAEncryption
        Blah blah

답변1

크로스듀프https://stackoverflow.com/questions/3093112/certificateException-no-name-matching-ssl-someurl-de-found.

주체 일반 이름은 더 이상 HTTPS 인증서를 제어하지 않습니다.

AFAICT 실제로 그렇게 말하는 표준은 없지만몇 년 동안의 관행은 브라우저 등이 존재하는 경우 SubjectAlternativeName(SAN) 확장을 사용하고 SAN이 없는 경우에만 주제의 CommonName(CN)을 사용하는 것입니다. 귀하의 인증서에는 SAN이 있으므로 dcrdev.com해당 항목만 일치합니다.

업데이트:에서 발견RFC2818 3.1:

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

해당 RFC는 2000년 5월이었지만, 제가 기억하기로는 제가 만난 인증서는 2010년이 가까워질 때까지 SAN을 사용하기 시작하지 않았습니다. 가장 최근인 2011년 3월입니다.RFC6125@JennyD로 식별된 것(답변 본문에서 작동합니까?)은 보다 일반적인 치료법이지만 명시적으로 다음과 같이 말합니다.

또한 이 문서는 부록 B에서 발췌한 것과 같이 이 문서 이전에 게시된 기존 애플리케이션 프로토콜에 대한 사양에 제공된 서비스 ID 확인 규칙을 대체하지 않습니다.

부록 B에는 RFC2818이 포함되어 있습니다.

기본 요구 사항CA-브라우저 포럼CA가 반드시 해야 한다고 말합니까?문제브라우저/클라이언트에서 직접적으로 요구되는 것은 아니지만 Subject.CN은 더 이상 사용되지 않습니다.

도메인과 하위 도메인을 모두 사용하려면(한 수준만) SAN에 두 개의 dnsName 항목(하나는 dcrdev.com, 하나는 ) 을 넣습니다 *.dcrdev.com.

관련 정보