假定SSL证书的使用者备用名称（SAN）属性包含两个DNS名称

1. domain.tld
2. host.domain.tld

但是“通用名称（CN）”仅设置为以下两者之一CN=domain.tld。

• 此设置是否具有特殊含义，或在设置两个CN方面有任何[缺点]？
• 如果host.domain.tld请求另一个服务器在服务器端会发生什么？

具体来说，OpenSSL 0.9.8b +如何处理给定方案？

这取决于实现方式，但是一般规则是针对所有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中的备用域名。即，如果存在SAN，则将CN从验证中排除，您可以拒绝其他有效的证书。

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

CN字段应包含使用者名称而不是域名，但是当Netscape发现此SSL内容时，他们错过了定义其最大市场的机会。只是没有为服务器URL定义证书字段。

解决了将域放入CN字段的问题，如今已弃用CN字段，但仍被广泛使用。CN只能保存一个域名。

通用规则：CN-将您的主URL放在此处（出于兼容性考虑）SAN-将您的所有域放在此处，重复CN，因为CN不在此处，但用于此...

如果找到正确的实现，则对以下问题的回答如下：

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

• 如果请求另一个host.domain.tld，在服务器端会发生什么情况？不管服务器端发生了什么。

简而言之：当浏览器客户端连接到该服务器时，浏览器将发送加密的软件包，并使用服务器的公共密钥对其进行加密。服务器解密该程序包，如果服务器可以解密，则说明该服务器已被加密。

在解密之前，服务器对客户端一无所知，因为只有IP地址未通过连接进行加密。这就是为什么您需要2个IP才能获得2个证书的原因。（忘记SNI，现在仍然有太多XP。）

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

CABForum基准要求

我认为还没有人提到基准要求中的这一部分。我觉得它们很重要。

问： SSL-公用名（CN）和使用者备用名（SAN）如何一起使用？
答：完全没有。如果有SAN，则可以忽略CN。-至少进行检查的软件非常严格地遵守CABForum的基准要求。

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

CABForum基准要求，v。1.2.5（截至2015年4月2日），第9-10页：

9.2.2主体的标识名称字段
一个。主题公用名字段
证书字段： subject：commonName（OID 2.5.4.3）
必需/可选：已弃用（已淘汰，但不是禁止的）
内容：如果存在，则此字段必须包含一个IP地址或一个全限定域名证书的subjectAltName扩展名中包含的值（请参阅第9.2.1节）。

编辑：@Bruno评论的链接

RFC 2818： HTTP over TLS，2000，第3.1节：服务器身份：

如果存在类型为dNSName的subjectAltName扩展名，则该扩展名必须用作标识。否则，必须使用证书的“主题”字段中的（最特定的）“公共名称”字段。尽管使用通用名称是现有做法，但不建议使用通用名称，建议鼓励证书颁发机构改为使用dNSName。

RFC 6125： 在传输层安全性（TLS）上下文中使用X.509（PKIX）证书在Internet公钥基础结构中表示和验证基于域的应用程序服务身份，2011年，第6.4.4节：通用名称检查：

[...]当且仅当所提供的标识符不包括DNS-ID，SRV-ID，URI-ID或客户端支持的任何特定于应用程序的标识符类型时，客户端才可以作为最后的选择一个字符串，其格式与主题字段的“通用名称”字段中的标准DNS域名的格式匹配（即，CN-ID）。