>假设 SSL 证书的使用者备用名称 （SAN） 属性包含两个 DNS 名称
-
domain.example -
host.domain.example
但公用名 （CN） 仅设置为两者之一：CN=domain.example 。
- 与设置两个CN相比，此设置是否有特殊含义或任何[缺点]？
- 如果请求另一个
host.domain.example，服务器端会发生什么？
具体来说，OpenSSL 0.9.8b+ 如何处理给定的场景？
这取决于实现，但一般规则是针对所有 SAN 和公用名检查域。如果在那里找到域，则证书可以连接。
RFC 5280 第 4.1.2.6 节说"主题名称可以在主题字段和/或主题 AltName 扩展名中携带"。这意味着必须根据证书的 SubjectAltName 扩展名和 Subject 属性（即其公用名参数）检查域名。这两个地方相辅相成，不相互重复。SubjectAltName 是放置其他名称的合适位置，例如 www.domain.example 或 www2.domain.example
更新：根据 2011 年发布的 RFC 6125，验证器必须首先检查 SAN，如果 SAN 存在，则不应检查 CN。请注意，RFC 6125 相对较新，仍然存在颁发证书的证书和 CA，其中包括 CN 中的"主"域名和 SAN 中的备用域名。换句话说，如果存在 SAN，则通过从验证中排除 CN，可以拒绝某些原本有效的证书。
为了绝对正确，您应该将所有名称放入 SAN 字段中。
CN字段应该包含一个主题名称而不是域名，但是当Netscape发现这个SSL的东西时，他们错过了定义其最大的市场。只是没有为服务器 URL 定义证书字段。
解决了将域放入CN字段的问题，如今CN字段的使用已被弃用，但仍被广泛使用。CN 只能保存一个域名。
这方面的一般规则：CN - 在此处输入您的主网址（为了兼容）SAN - 把你所有的域名都放在这里，重复CN，因为它不在那里，但它用于那个......
如果您找到了正确的实现，则问题的答案如下：
-
此设置是否具有特殊意义，或者与设置两个 CN 相比有任何 [缺点] 优势？不能同时设置两个 CN，因为 CN 只能保存一个名称。您可以使用 2 个简单的 CN 证书而不是一个 CN+SAN 证书，但为此需要 2 个 IP 地址。
-
如果请求另一个 host.domain.tld，在服务器端会发生什么？服务器端发生什么并不重要。
总之：当浏览器客户端连接到此服务器时，浏览器会发送加密包，这些包使用服务器的公钥进行加密。服务器解密包，如果服务器可以解密，则为服务器加密包。
在解密之前，服务器不知道客户端的任何内容，因为只有 IP 地址没有通过连接进行加密。这就是为什么您需要 2 个 IP 用于 2 个证书的原因。（忘记SNI，现在还有太多的经验值。
在客户端，浏览器获取CN，然后获取SAN，直到检查完所有内容。如果其中一个名称与网站匹配，则网址验证是由浏览器完成的。（我不是在谈论证书验证，当然很多OCSP，CRL，AIA请求和答案每次都在网上传播。
CABForum 基线要求
我看到还没有人在基线要求中提到该部分。我觉得它们很重要。
问：SSL - 公用名 （CN） 和使用者备用名称 （SAN） 如何协同工作？
一个：一点也不。如果有 SAN，则可以忽略 CN。- 至少如果执行检查的软件非常严格地遵守CABForum的基线要求。
（所以这意味着我无法回答您的问题的"编辑"。只有原来的问题。
CABForum 基线要求，第 1.2.5 版（截至 2015 年 4 月 2 日），第 9-10 页：
9.2.2 主题可分辨名称字段
a. 使用者公用名字段
证书字段：主题：公用名 （OID 2.5.4.3）
必需/可选：已弃用（不鼓励，但不禁止）
内容：如果存在，此字段必须包含单个 IP 地址或完全限定域名，该地址或完全限定域名是证书的主题 AltName 扩展中包含的值之一（请参阅第 9.2.1 节）。
编辑：来自@Bruno评论的链接
RFC 2818：HTTP over TLS，2000，第 3.1 节：服务器标识：
如果存在 dNSName 类型的 subjectAltName 扩展名，则必须用作标识。否则，（最具体的）公用名必须使用证书的"主题"字段中的字段。虽然使用公用名是现有做法，已弃用，并且鼓励证书颁发机构改用 dNSName。
RFC 6125： 基于域的应用程序服务的表示和验证使用 X.509 （PKIX） 的互联网公钥基础结构中的标识传输层安全性 （TLS） 上下文中的证书，2011 年，第 6.4.4 节：公用名检查：
[...]当且仅当提供的标识符不包含DNS-ID、SRV-ID、URI-ID 或任何特定于应用程序的标识符类型由客户端支持，然后客户端可以作为最后的手段检查对于其形式与完全限定的 DNS 域的形式匹配的字符串主题字段的公用名字段中的名称（即 CN-ID）。
很高兴知道：Chrome 几年前在 2017 年放弃了 CN 支持
更新已添加 2023-04-27。
- 摘要博客文章：https://xenit.se/blog/2018/04/08/chrome-certificate-warning-invalid-common-name/
- "删除意图：支持证书中的公用名匹配2"： https://groups.google.com/a/chromium.org/g/security-dev/c/IGT2fLJrAeo/m/csf_1Rh1AwAJ
- "问题 308330：删除对证书中公用名的支持;仅支持使用者替代名称"https://bugs.chromium.org/p/chromium/issues/detail?id=308330