%2F%E4%B8%BB%E4%BD%93%E5%A4%87%E7%94%A8%E5%90%8D%E7%A7%B0%20(SAN)%20%E5%9C%A8%20Microsoft%20%E5%85%AC%E9%92%A5%E5%9F%BA%E7%A1%80%E8%AE%BE%E6%96%BD%20(PKI)%20%E4%B8%AD%E8%B5%B7%E4%BB%80%E4%B9%88%E4%BD%9C%E7%94%A8%EF%BC%9F.png)
什么是主题名称/主题备用名称以及它们彼此有何不同？
特别是“主题名称”选项卡下方的模板。除了在注册证书时需要将信息放入主题选项卡中的额外步骤之外，这对普通证书申请有何影响？
主题名称 (SN)/主题备用名称 (SAN) 在 Microsoft 公钥基础结构 (PKI) 中的作用是什么？SAN 如何使用？哪些场景可从将其纳入证书中受益？
答案1
证书将公钥绑定到主体。证书的主体是持有者的详细信息。您的问题就像问“护照上的姓名有什么用处？“。
主题字段和主题备用名称 (SAN) 扩展都只是识别主题或持有者的两种方式。
最初，在版本 1 证书中，没有证书扩展的概念（例如主题备用名称和基本约束），定义证书主题的唯一方法是使用主题字段。这需要一个可分辨名称，该名称在 X.500 中定义，由通用名称 (CN)、组织 (O) 和国家 (C) 等元素组成。这对于公司地址甚至个人地址等地址来说相当有效，但对于 DNS 系统则不太适用 - 据我所知，X.500 中没有主机名元素。如果您查看此站点的证书，您会发现颁发者是：CN = E1, O = Let's Encrypt, C = US- 并非不合理。
作为证书验证过程的一部分，浏览器希望其地址栏中输入的 URL 的主机名元素与服务器证书的主题相匹配。浏览器供应商希望主机的 FQDN 作为通用名称输入到证书中（查看此站点的证书，您将看到 CN 为serverfault.com）。
但是，在 CN 中输入服务器的 FQDN 有点不妥 - 如果我们在浏览器中输入服务器的 IP 地址会怎么样？此外，如果证书的主题由其他内容标识，例如 Windows 中客户端证书的 UPN，会怎么样？我们是否也要将其挤进 CN，或将其添加为电子邮件元素？这可能会变得混乱并容易出错。
版本 3 证书引入了扩展的概念，其中一个扩展是主题备用名称 (SAN)。这允许更详细地定义名称类型。例如，它支持 DNS、IP 地址、电子邮件地址、URL 等。因此，客户端不必猜测主题指的是什么。SAN 还可以包含多个条目，因此您可以为服务器的 FQDN 设置一个条目，为其 IP 地址设置另一个条目，因此在浏览器中输入任何一个条目都被视为有效。
如今，浏览器甚至不查看主题字段，并期望服务器的主题（DNS，IP地址等）位于SAN中。
RFC 5280如果你想更详细地了解它们的含义，这将是一本不错的睡前读物，RFC 2818 第 3.1 节简单解释了它们在 HTTPS 上下文中的用法。有关匹配主题名称的更一般性讨论，请考虑RFC 6125（或者简单地看一下它的简洁标题:-)）
答案2
主题名称标识颁发证书的名称。例如，对于像 google.com 这样的网站，其中一个是 google.com，另一个是www.google.com
答案3
主题名称只是您希望公共证书有效的域的 FQDN。
主题备用名称 (SAN) 是您希望相同的证书也有效。当您希望单个证书“覆盖”多个 FQDN 时，SAN 非常有用。
例如，如果您正在部署 Kubernetes 集群，您可能需要为、和 获得一个证书api.<cluster>.<domain>，api-int.<cluster>.<domain>而*.apps.<cluster>.<domain>不是订购三个单独的证书。
这只是使总体证书数量减少（从而更易于管理），同时仍然保护和覆盖系统的每个组件。