为什么我的通配符自签名证书出现 URL 不匹配？

Question

我正在尝试设置供 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/emailAddress=webmaster@dcrdev.com
        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/emailAddress=administrator@dcrdev.com
        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/emailAddress=webmaster@dcrdev.com
        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

Answer 1

/sf/ask/216517871/ 的交叉复制。

主题通用名称不再控制 HTTPS 证书。

AFAICT 实际上没有标准的说法，但是几年来的实践是，浏览器等使用 SubjectAlternativeName (SAN) 扩展（如果存在），并且只有在 SAN 不存在时才使用主题中的 CommonName（CN）。您的证书有 SAN 存在dcrdev.com，因此只有匹配。

更新：在RFC2818 3.1 中找到：

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

该 RFC 是 2000 年 5 月，但据我回忆，我遇到的证书直到 2010 年才开始使用 SAN。@JennyD确定的最近的 2011 年 3 月RFC6125（它在答案正文中有效吗？）是一种更通用的处理方式，但明确表示

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

附录 B 包括 RFC2818。

CA-Browser Forum的 Baseline Requirements确实说 CA 必须向 SAN颁发证书，而 Subject.CN 已被弃用，尽管这不是对浏览器/客户端的直接要求。

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