通用名称 (CN) 和主题备用名称 (SAN) 如何协同工作？
假设 SSL 证书的主题备用名称 (SAN) 属性包含两个 DNS 名称
domain.examplehost.domain.example
但通用名称 (CN) 设置为仅两者之一：CN=domain.example。
- 此设置是否有特殊含义，或者比设置两个 CN 有什么优势吗？
- 如果请求另一个
host.domain.example，服务器端会发生什么？
具体来说，OpenSSL 0.9.8b+ 如何处理给定的场景？
Assuming the Subject Alternative Name (SAN) property of an SSL certificate contains two DNS names
domain.examplehost.domain.example
but the Common Name (CN) is set to only one of both: CN=domain.example.
- Does this setup have a special meaning, or any [dis]advantages over setting both CNs?
- What happens on server-side if the other one,
host.domain.example, is being requested?
Specifically, how does OpenSSL 0.9.8b+ handle the given scenario?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这取决于实施，但一般规则是根据所有 SAN 和公用名称检查域。如果在那里找到该域，则证书可以进行连接。
RFC 5280，第 4.1.2.6 节说“主题名称可以被携带在主题字段和/或 subjectAltName 扩展中”。这意味着必须根据证书的SubjectAltName 扩展名和Subject 属性（即其公用名称参数）检查域名。这两个地方是互补的，而不是重复的。 SubjectAltName 是放置其他名称的合适位置，例如 www.domain.example 或 www2.domain.example
更新：按照 RFC 6125，2011年发布，验证者必须首先检查SAN，如果 SAN 存在，则不应检查 CN。请注意，RFC 6125 相对较新，并且仍然存在证书和颁发证书的 CA，其中包括 CN 中的“主”域名和 SAN 中的备用域名。换句话说，如果存在 SAN，则通过从验证中排除 CN，您可以拒绝某些其他有效的证书。
This depends on implementation, but the general rule is that the domain is checked against all SANs and the common name. If the domain is found there, then the certificate is OK for connection.
RFC 5280, section 4.1.2.6 says "The subject name MAY be carried in the subject field and/or the subjectAltName extension". This means that the domain name must be checked against both SubjectAltName extension and Subject property (namely its common name parameter) of the certificate. These two places complement each other, not duplicate each other. And SubjectAltName is a proper place to put additional names, such as www.domain.example or www2.domain.example
Update: as per RFC 6125, published in 2011, the validator must check SAN first, and if SAN exists, then CN should not be checked. Note that RFC 6125 is relatively recent and there still exist certificates and CAs that issue certificates, which include the "main" domain name in CN and alternative domain names in SAN. In other words, by excluding CN from validation if SAN is present, you can deny some otherwise valid certificate.
为了绝对正确，您应该将所有名称放入 SAN 字段。
CN 字段应该包含主题名称而不是域名，但是当 Netscape 发现 SSL 这个东西时，他们错过了定义其最大的市场。
只是没有为服务器 URL 定义证书字段。
解决这个问题的方法是将该域放入 CN 字段，现在 CN 字段的使用已被弃用，但仍然广泛使用。
CN 只能拥有一个域名。
一般规则：
CN - 在此填写您的主要 URL（为了兼容性）
SAN - 将您的所有域放在这里，重复 CN，因为它不在正确的位置，但它用于此...
如果您找到正确的实现，您的问题的答案将如下：
有此设置有特殊含义，或者比设置两个 CN 有任何[dis]优势吗？
您不能同时设置两个 CN，因为 CN 只能保存一个名称。
您可以使用 2 个简单的 CN 证书代替 1 个 CN+SAN 证书，但为此需要 2 个 IP 地址。
如果请求另一个 host.domain.tld，服务器端会发生什么？
服务器端发生什么并不重要。
简而言之：
当浏览器客户端连接到该服务器时，浏览器会发送加密包，这些包是使用服务器的公钥加密的。服务器解密该包，如果服务器可以解密，则该包已为服务器加密。
服务器在解密之前不知道客户端的任何信息，因为只有 IP 地址通过连接未加密。这就是为什么 2 个证书需要 2 个 IP。 （忘记 SNI，现在仍然有太多 XP。）
在客户端，浏览器获取 CN，然后获取 SAN，直到检查完所有内容。
如果其中一个名称与该站点匹配，则 URL 验证由浏览器完成。
（我不是在谈论证书验证，当然，每次都有很多 ocsp、crl、aia 请求和答案在网上传播。）
To be absolutely correct you should put all the names into the SAN field.
The CN field should contain a Subject Name not a domain name, but when the Netscape found out this SSL thing, they missed to define its greatest market.
Simply there was not certificate field defined for the Server URL.
This was solved to put the domain into the CN field, and nowadays usage of the CN field is deprecated, but still widely used.
The CN can hold only one domain name.
The general rules for this:
CN - put here your main URL (for compatibility)
SAN - put all your domain here, repeat the CN because its not in right place there, but its used for that...
If you found a correct implementation, the answers for your questions will be the followings:
Has this setup a special meaning, or any [dis]advantages over setting both CNs?
You cant set both CNs, because CN can hold only one name.
You can make with 2 simple CN certificate instead one CN+SAN certificate, but you need 2 IP addresses for this.
What happens on server-side if the other one, host.domain.tld, is being requested?
It doesn't matter whats happen on server side.
In short:
When a browser client connects to this server, then the browser sends encrypted packages, which are encrypted with the public key of the server. Server decrypts the package, and if server can decrypt, then it was encrypted for the server.
The server doesn't know anything from the client before decrypt, because only the IP address is not encrypted trough the connection. This is why you need 2 IPs for 2 certificates. (Forget SNI, there is too much XP out there still now.)
On client side the browser gets the CN, then the SAN until all of the are checked.
If one of the names matches for the site, then the URL verification was done by the browser.
(im not talking on the certificate verification, of course a lot of ocsp, crl, aia request and answers travels on the net every time.)
CABForum 基线要求
我发现还没有人提到基线要求中的这一节。我感觉他们很重要。
问： SSL - 通用名称 (CN) 和主题备用名称 (SAN) 如何协同工作？
答：完全没有。如果有SAN，那么CN可以忽略。 -- 至少进行检查的软件非常严格地遵守 CABForum 的基准要求。
（所以这意味着我无法回答您问题的“编辑”。只能回答原始问题。）
CABForum 基线要求，v. 1.2.5（截至 2015 年 4 月 2 日），第 9-10 页：
编辑：来自@Bruno评论的链接
RFC 2818： HTTP Over TLS，2000，第 3.1 节：服务器身份：
RFC 6125： 基于域的应用程序服务的表示和验证
使用 X.509 (PKIX) 的互联网公钥基础设施中的身份
传输层安全 (TLS) 环境中的证书，2011 年，第 6.4.4 节：通用名称检查：
很高兴知道：Chrome 几年前在 2017 年
更新（2023 年 4 月 27 日添加）中放弃了 CN 支持。
2"：https ://groups.google.com/a/chromium.org/g/security-dev/c/IGT2fLJrAeo/m/csf_1Rh1AwAJ
CABForum Baseline Requirements
I see no one has mentioned the section in the Baseline Requirements yet. I feel they are important.
Q: SSL - How do Common Names (CN) and Subject Alternative Names (SAN) work together?
A: Not at all. If there are SANs, then CN can be ignored. -- At least if the software that does the checking adheres very strictly to the CABForum's Baseline Requirements.
(So this means I can't answer the "Edit" to your question. Only the original question.)
CABForum Baseline Requirements, v. 1.2.5 (as of 2 April 2015), page 9-10:
EDIT: Links from @Bruno's comment
RFC 2818: HTTP Over TLS, 2000, Section 3.1: Server Identity:
RFC 6125: Representation and Verification of Domain-Based Application Service
Identity within Internet Public Key Infrastructure Using X.509 (PKIX)
Certificates in the Context of Transport Layer Security (TLS), 2011, Section 6.4.4: Checking of Common Names:
Nice to know: Chrome threw out CN support years ago in 2017
Update added 2023-04-27.
2": https://groups.google.com/a/chromium.org/g/security-dev/c/IGT2fLJrAeo/m/csf_1Rh1AwAJ