☰

单个子域名是否需要通配符 SSL？

tag-icon • tag-icon apache-2.2 ssl subdomain shared-hosting
单个子域名是否需要通配符 SSL？

典型的 SSL 证书基于域名的通用名称 (domain.com)，有时也基于 (www.domain.com)。

我了解通配符证书的用途（*.domain.com），并且它会/应该验证该域的所有子域。

如果我想用 SSL 证书覆盖单个子域名（mail.domain.com），通配符证书是否仅有的选项？或者是否可以使用为该单个子域颁发的标准 SSL 证书？

我并不是在寻求最佳实践，也不是在寻求“为什么真的应该使用通配符证书”的理由。我是在从技术角度询问是否可以使用非通配符的 SSL 域验证证书来保护单个子域。

答案1

您可以毫无问题地使用仅为 mail.domain.com 颁发的 SSL 证书。通配符证书的最大优势是“一个证书可以统治所有证书” - 您无需管理数十个证书。

答案2

如果您拥有“domain.com”，您也可以申请“mail.domain.com”的证书。您只需要证明您对根域的所有权。

答案3

是的，您可以拥有仅涵盖特定子域的证书。您还可以拥有涵盖多个子域的证书，而无需使用通配符。

请注意，SSL/TLS 传统上只允许每个 IP/端口组合使用一个证书。有一个名为 SNI 的扩展可以解决这个问题，但仍有一些较旧的客户端不支持它（最明显的是 Windows XP 上的 Internet Explorer）。

答案4

一开始我对这个问题有点困惑，因为证书通常被认为在典型情况下只提供一个主题。使用 SSL 域验证证书保护单个 DNS 记录（/子域，参见第 3 节）不是吗？通配符网站的标准情况？

简而言之，如果子域 mail.domain.com 是其自身资源的连接字符串，您可以而且应该使用单个非通配符证书来保护子域 mail.domain.com 的安全，但您不应该期望该子域中的记录也被同一个证书覆盖。

这当前接受的答案为一般情况提供了一个很好的简洁答案，但在推荐通配符证书时可能会带来意想不到的警告。因此，为了防止对什么产生潜在的危险误解，最终实体关于各种类型的证书可以做什么和不能做什么，我想更深入地讲一下，分为三个部分：

  1. 通配符/非通配符选择
  2. 证书上的姓名与您能出示的内容有何关系
  3. 在问题的上下文中，子域名的含义是什么。

第 1 部分：通配符与非通配符

  • 定价：这是我首先要提到的。商业 CA 对通配符证书的收费是标准证书的 3-5 倍。例如，在撰写本文时，来自赛门铁克（原先是 VeriSign）的价格为 399 美元。一年期通配符证书的价格为 1,999 美元（~x5 标准）。赛门铁克安全站点证书（更便宜的选择）可以与主题备用名称一起使用（SAN），这意味着只要您知道您正在使用的并将在明年使用的面向公众的 DNS 名称，即使对于多个网站或安全连接点，您也不需要通配符证书。

  • 潜在暴露范围：如上文评论所述，如果私钥泄露，则暴露程度不同。使用单个 Web 服务器的证书，攻击者只能冒充该服务器。对于单个网站，只有该网站名称解析的服务器（请参阅第 2 节 - 主题名称匹配）。使用我上面的一个 SAN 证书上的所有面向公众的名称的想法，他们可以冒充您所有面向公众的网站。使用通配符证书，他们可以冒充任何东西并声称它来自您的域。反对通配符证书的安全论点已在 RFC 中提出。

  • 名称匹配：非通配符证书仅匹配精确的主体名称（特别是大多数证书的主体名称的通用名称或 CN 组件）。因此，任何与 mail.domain.com 绑定的证书解析都可以工作，即使它涉及 CNAMES 或对多个 IP 地址的解析，但例如 smtp.mail.domain.com（或更典型的用法）[电子邮件保护]) 都无法工作，除非它们配置为 SAN。在这种情况下，通配符证书 *.mail.domain.com 适用于 smtp.mail.domain.com（在我们的安全邮件示例中，假设两者id-pkix 3 4你呢手动配置通配符 S/MIME）。

  • 面向未来：这是大多数建议仅使用通配符的原因。使用主 DNS 域“domain.com”的通配符证书，您可以在 domain.com 下托管任意数量的网站，即使是您在请求证书时不知道需要的网站。您永远不需要担心检查提供的证书是否与网站名称匹配，因为它始终匹配。

  • 规划：关于未来防护的要点，请注意，使用多 SAN 证书，只要您包含所有当前和计划的未来网站，管理的简易性是相同的。您有几十个名称可以使用，因此您甚至可以添加您不打算使用但您认为组织可能会使用的 DNS 名称。即使您在年中需要一个您没有计划的名称，购买另一个多 SAN 证书仍然可以让您花费不到通配符证书费用的一半。

  • 通配符限制：考虑到价格差异的大小，我不确定非通配符的小额管理开销是否值得购买通配符证书，除非您是一家大型组织，需要保护数十到数百个面向公众的 DNS 名称。另外请记住，通配符仅匹配 domain.com 下 DNS 层次结构中的一个级别。因此，如果您想要 www.*.domain.com，则需要专门针对 www.[specificsubdomain].domain.com 的新证书或针对 *.*.domain.com 或 www.*.domain.com 的通配符证书的 SAN。请注意，CA 通常不愿意/拒绝将 SAN 添加到通配符证书中。

第 2 部分：主题名称匹配

需要记住的一点是，验证基于客户端上的主题字符串与证书中声明的内容相匹配。对于 Web 浏览器，这是输入到地址栏以访问页面的数据。对于电子邮件客户端，代表源电子邮件地址等等，适用于各种客户端类型和证书用途。

因此，对于 Web 服务器证书，如果我在 DNS 中有以下内容：

www.otherdomain.org172.16.254.1

但是在特定机器上的 hosts 文件中：

172.16.254.1 邮件.域.org

该特定机器的主题名称将与服务器 172.16.254.1 上为 mail.domain.org 提供证书的服务器匹配，但客户端通过 DNS 查找到达 172.16.254.1www.otherdomain.org同一证书将出现主题名称不匹配的情况。如果我在 DNS 中添加此 CNAME：

mail.domain.org CNAMEwww.otherdomain.org

并要求我的所有客户在浏览器中访问 mail.domain.org，而不是www.otherdomain.org，证书现在将不再向这些客户端显示证书名称不匹配。这是因为 DNS 解析对浏览器来说是不透明的。

第 3 节：DNS 术语

我还想指出这个术语可能有点令人困惑，当你提到“子域”时，我的结论是一个完整的区域，在你的主名称服务器所在的父区域/域之下，这个子域可能有自己的名称服务器和下属记录。

（虽然在 DNS 层次结构中，从技术上讲，除了根之外的所有内容都是子域，但人们倾向于将层次结构中没有下属的记录视为“非子域”，因为从概念上讲，它们满足“子”的要求，但不一定满足适当“领域'。例如，您通常不会将 A 记录视为具有管理自主权，即使您稍后可以添加名称服务器记录并在其下填充查找。我知道这种倾向并不一定与技术现实相符。）

对于解析为单个“资源”（网站、服务器、工作站）的记录，我通常会使用“网站/服务器/工作站”、通用的“DNS 记录”、“主机（A）记录”，或者为了涵盖 CNAME、F5 魔法等的可能性，至少使用“[网站/服务器/非子域资源类型]完全合格域名'（FQDN）

相关内容