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

EN

这取决于实施情况，但一般规则是根据所有SAN和通用名称对域进行检查。如果在那里找到了域，则证书可以用于连接。

RFC 5280，第4.1.2.6节说“主题名称可以在subject字段和/或subjectAltName扩展中携带”。这意味着域名必须根据证书的SubjectAltName扩展和Subject属性(即其公共名称参数)进行检查。这两个地方是互补的，而不是重复的。SubjectAltName是放置其他名称的合适位置，比如www.domain.com或www2.domain.com

更新:根据2011年发布的RFC 6125，验证器必须首先检查SAN，如果SAN存在，则不应检查CN。请注意，RFC 6125相对较新，仍然存在颁发证书的证书和CA，其中包括CN中的“主”域名和SAN中的替代域名。例如，如果存在SAN，则通过将CN排除在验证之外，您可以拒绝某些其他有效的证书。

要绝对正确，您应该将所有名称输入SAN字段。

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

解决了将域放入CN字段中的问题，目前CN字段已被弃用，但仍被广泛使用。CN只能包含一个域名。

一般的规则是: CN -把你的主URL放在这里(为了兼容性) SAN -把你所有的域名放在这里，重复CN，因为它不在正确的地方，但它是用来做这个的…

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

• 这个设置有特殊的意义，或者比设置两个CN有什么缺点吗？您不能同时设置CN，因为CN只能包含一个名称。你可以用两个简单的CN证书代替一个CN+SAN证书，但你需要两个IP地址。
• 如果请求另一个host.domain.tld，服务器端会发生什么？在服务器端发生什么并不重要。

简而言之:当浏览器客户端连接到此服务器时，浏览器将发送加密的包，这些包是使用服务器的公钥加密的。服务器对包进行解密，如果服务器可以解密，则它是为服务器加密的。

在解密之前，服务器不知道来自客户端的任何信息，因为只有IP地址没有通过连接加密。这就是为什么2个证书需要2个IP的原因。(忘了SNI吧，现在仍然有太多的XP。)

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

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

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

A:完全不是。如果存在can，则可以忽略CN。--至少如果进行检查的软件严格遵守CABForum的基准要求。

(这意味着我无法回答您的问题的“编辑”。仅原始问题。)

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

9.2.2主题可分辨名称字段

a.主题常用名称字段

证书字段：主题:通用名称(OID2.5.4.3)

Required/Optional:已弃用(不推荐使用，但不禁止)

内容：如果存在，此字段必须包含单个IP地址或完全限定的域名，该地址或完全限定的域名是证书的subjectAltName扩展中包含的值之一(请参阅第9.2.1节)。

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

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

PKIXRFC6125:在传输层安全上下文中使用X.509 ()证书在互联网公钥基础设施内进行基于域的应用程序服务身份的表示和验证，2011，Section 6.4.4: Checking of Common Names

...当且仅当所呈现的标识符不包括DNS-ID、SRV-ID、URI-ID或客户端支持的任何特定于应用的标识符类型时，客户端可以作为最后手段来检查其形式与主题字段(即CN-ID)的公共名称字段中的完全限定的DNS域名相匹配的字符串。