為什麼我的通配符自簽名憑證上出現 URL 不符的情況?

為什麼我的通配符自簽名憑證上出現 URL 不符的情況?

我正在嘗試設定一個自簽名通配符憑證以供 Apache 使用,通常這非常簡單,我只需使用根網域設定主題備用名稱,並在通用名稱欄位中指定 *.dcrdev.com。然而,這似乎不起作用- 當我嘗試在chrome 中訪問該網站或在sslabs 中測試它時,他們在訪問任何子域(例如www.dcrdev.com 或subdomain1.dcrdev.com)時報告URL 不匹配。我不知道為什麼,當我在 chrome 中查看證書資訊時,它顯示的通用名稱為 *.dcrdev.com。

我的企業社會責任:

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 擴展,則必須將其用作身分。否則,必須使用憑證主題欄位中的(最具體的)通用名稱欄位。儘管使用通用名稱是現有做法,但它已被棄用,並鼓勵憑證授權單位改用 dNSName。

該 RFC 是 2000 年 5 月,但據我記得,我遇到的憑證直到接近 2010 年才開始使用 SAN。RFC6125由 @JennyD 識別(它在答案正文中起作用嗎?)是一種更通用的處理方法,但明確表示

本文檔也不取代本文檔先前發布的現有應用程式協定規範中提供的驗證服務身分的規則,例如附錄 B 中摘錄的規則。

附錄 B 包括 RFC2818。

基線要求來自CA-瀏覽器論壇確實是說 CA 必須問題使用 SAN 進行證書,而Subject.CN 已被棄用,儘管這並不是瀏覽器/客戶端的直接要求。

如果您想同時使用網域和子網域(僅一級),請在 SAN 中放置兩個 dnsName 條目,一個dcrdev.com用於*.dcrdev.com.

相關內容