☰

为什么我的通配符自签名证书会出现 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。

我的企业社会责任：

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 证书。

据我所知，实际上并没有一个标准的说法，但是多年来的惯例是，如果存在，浏览器等会使用 SubjectAlternativeName (SAN) 扩展，如果不存在 SAN，则仅在 Subject 中才使用 CommonName (CN)。您的证书具有 SAN dcrdev.com，因此只有 匹配。

更新：在发现RFC2818 3.1：

如果存在 dNSName 类型的 subjectAltName 扩展，则必须将其用作身份。否则，必须使用证书主题字段中的（最具体的）通用名称字段。虽然使用通用名称是现行做法，但已弃用，并鼓励证书颁发机构改用 dNSName。

该 RFC 是 2000 年 5 月发布的，但据我回忆，我遇到的证书直到 2010 年左右才开始使用 SAN。最近的一次是 2011 年 3 月RFC6125由@JennyD 识别（它在答案主体中起作用吗？）是一种更通用的处理方法，但明确指出

本文档也不会取代本文档之前发布的现有应用协议规范中提供的验证服务身份的规则，例如附录 B 中摘录的规则。

附录B包括RFC2818。

基本要求来自CA-浏览器论坛确实说 CA 必须问题虽然这并不是浏览器/客户端的直接要求，但 Subject.CN 已被弃用，因此需要使用 SAN 证书。

如果您想要同时使用域和子域（仅限一个级别），请在 SAN 中放置两个 dnsName 条目，一个用于dcrdev.com，一个用于*.dcrdev.com。

相关内容