通用名称 (CN) 和主题备用名称 (SAN) 如何协同工作？

Posted 2023-02-25

【中文标题】通用名称 (CN) 和主题备用名称 (SAN) 如何协同工作？

【英文标题】：How do Common Names (CN) and Subject Alternative Names (SAN) work together?

【发布时间】：2011-08-21 13:53:10

【问题描述】：

假设 SSL 证书的主题备用名称 (SAN) 属性包含两个 DNS 名称

domain.tld host.domain.tld

但通用名称 (CN) 仅设置为两者之一：CN=domain.tld。

此设置是否有特殊含义，或者与设置两个 CN 相比有任何 [缺点] 优势吗？ 如果另一个host.domain.tld 被请求，服务器端会发生什么？

具体来说，OpenSSL 0.9.8b+ 如何处理给定的场景？

【参考方案1】：

这取决于实现，但一般规则是根据所有 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 相对较新，仍然存在颁发证书的证书和 CA，其中包括 CN 中的“主”域名和 SAN 中的备用域名。 IE。如果存在 SAN，则通过从验证中排除 CN，您可以拒绝某些其他有效的证书。

【讨论】：

这种短路一般吗？我的意思是，总是先检查 SAN，如果找到了，就根本不检查 CN？

如果您使用的是 IE，如果 subjectAltName 存在，它似乎会忽略 CN。我见过 IE10 和 IE8 在这种情况下都抱怨名称不匹配。

这对于 SSL 证书是不正确的。详情请看this答案。 TL;DR RFC 5280 仅适用于 PKI 结构。 RFC2818 和 RFC5216（针对 HTTPS）规定，如果 SAN 存在，那么它必须用于身份验证。

@Eugene Mayevski 'EldoS Corp 是的，抱歉 RFC5216 不适用于 HTTPS，让他们感到困惑。无论如何，Chrome 现在都会抛出 ERR_CERT_COMMON_NAME_INVALID 错误，因为它专门使用 SAN（如果存在）。

现在Chrome正式不再检查CN属性了。我的想法是这些字段可能应该更好地匹配证书中的功能。 chromestatus.com/feature/4981025180483584

【参考方案2】：

为了绝对正确，您应该将所有名称放入 SAN 字段中。

CN 字段应该包含一个主题名称而不是域名，但是当 Netscape 发现这个 SSL 东西时，他们错过了定义其最大市场的机会。 只是没有为服务器 URL 定义证书字段。

解决了将域放入 CN 字段的问题，现在 CN 字段的使用已被弃用，但仍被广泛使用。 CN 只能拥有一个域名。

一般规则： CN - 把你的主 URL 放在这里（为了兼容性） SAN - 把你所有的域名都放在这里，重复 CN，因为它不在正确的位置，但它用于那个......

如果您找到了正确的实现，您的问题的答案如下：

此设置是否有特殊含义，或者与设置两个 CN 相比有任何 [缺点] 优势吗？ 您不能同时设置两个 CN，因为 CN 只能包含一个名称。 您可以使用 2 个简单的 CN 证书代替 1 个 CN+SAN 证书，但您需要 2 个 IP 地址。

如果请求另一个，host.domain.tld，服务器端会发生什么？ 服务器端发生了什么并不重要。

简而言之： 当浏览器客户端连接到这个服务器时，浏览器会发送加密包，这些包是用服务器的公钥加密的。服务器解密包，如果服务器可以解密，那么它是为服务器加密的。

服务器在解密之前不知道来自客户端的任何信息，因为只有 IP 地址没有通过连接加密。这就是为什么您需要 2 个 IP 来获得 2 个证书。 （忘记 SNI，现在还有太多的 XP。）

在客户端，浏览器获取 CN，然后是 SAN，直到所有的都被检查。 如果其中一个名称与站点匹配，则 URL 验证由浏览器完成。 （我不是在谈论证书验证，当然每次都有很多ocsp，crl，aia请求和答案在网上传播。）

【参考方案3】：

#CABForum 基线要求 我看没有人提到基线要求中的部分。我觉得它们很重要。

问： SSL - 通用名称 (CN) 和主题备用名称 (SAN) 如何协同工作？答：完全没有。如果有 SAN，则可以忽略 CN。 -- 至少如果进行检查的软件非常严格地遵守 CABForum 的基线要求。

（所以这意味着我无法回答您的问题的“编辑”。只能回答原始问题。）

CABForum Baseline Requirements, v. 1.2.5 (as of 2 April 2015), page 9-10:

9.2.2 主题可分辨名称字段a.主题公用名字段证书字段： 主题：commonName (OID 2.5.4.3)必需/可选： 已弃用（不鼓励，但不是禁止）内容：如果存在，此字段必须包含单个 IP 地址或完全限定域名，它是证书的 subjectAltName 扩展中包含的值之一（请参阅第 9.2.1 节） .

###EDIT：来自@Bruno 评论的链接 RFC 2818： HTTP Over TLS，2000，Section 3.1: Server Identity：

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

RFC 6125： 基于域的应用服务的表示和验证 使用 X.509 (PKIX) 的 Internet 公钥基础设施中的身份 传输层安全 (TLS) 环境中的证书，2011，Section 6.4.4: Checking of Common Names：

[...] 当且仅当呈现的标识符不包含 DNS-ID、SRV-ID、URI-ID 或任何特定于应用程序的标识符类型 客户端支持，然后客户端可以作为最后的手段检查 对于其形式与完全限定的 DNS 域匹配的字符串 主题字段的通用名称字段中的名称（即 CN-ID）。

【讨论】：

这个 CABForum 基线要求规则在技术上不是很有用。它只是告诉您在 CN 中放入什么，但它当然并不意味着 CN 无论如何都用于验证。将 CN 作为 SAN 之一是有意义的，但这主要用于工具和管理目的（或反对过于宽松的实施）。从验证的角度来看，RFC 2818（“如果存在 dNSName 类型的 subjectAltName 扩展，则必须将其用作身份”），甚至 RFC 6125，在很大程度上早于该规范，并且特定规则在两者中仍然有效。

@Bruno：是的。谢谢。我已经包含了链接和引号