由于Let's Encrypt的公告，此答案中的信息现在仅具有历史价值。请参阅Emil Stensröm的回答中的信息。

IETF 标准化的 ACME v2 协议即将推出，Let's Encrypt 于 2017 年 6 月 14 日宣布，他们将在 2018 年 1 月针对该标准推出一个新的 API 端点。正如Emil在他的回答中所报告的，Let's Encrypt今天宣布（ 2017 年 6 月 6 日），他们将能够使用新的 API 端点来颁发急需的通配符证书。很好地抓住了埃米尔。

经过太长时间的评论交流，我决定收集并将它们扩展为答案。希望这会有所帮助。我避免讨论 OV 和 EV 证书，因为它们有完全不同的场景，问题的标题清楚地问 为什么 Let's Encrypt 不能支持通配符证书？

“为什么”最重要的是作为 LE 验证基础的ACME协议尚未涵盖通配符验证。如果没有这些，LE 根本无法颁发此类证书，无论他们是否愿意。但是，已经讨论过IETF ACME 邮件列表，因此至少有希望包含在协议中。此外，LE FAQ进一步解释了通配符证书不会被无限期排除。尽管他们最终可能会达到那种状态。

Let's Encrypt 会颁发通配符证书吗？

我们目前没有这样做的计划，但将来有可能。希望我们的绝大多数潜在订阅者不需要通配符，因为它应该很容易获取和管理所有子域的证书。

发行过程的自动化是Let's Encrypt 背后的关键原则。因此，任何无法自动化的事情都不会通过它们发生。这是他们在社区论坛的帖子中反复强调的一点。

自动发行通配符的部分问题在于它是如何完成的。HTTP 验证过程是证书服务器告诉请求代理（某些程序或脚本）在待验证的主机上创建一个唯一命名的文件，其中包含一些签名内容。然后证书服务器尝试访问该文件，并验证它的内容。如果可以检索到文件并且内容正确，则证明请求代理具有控制该主机的技术权限，并已通过证书验证。

如果我想为www.example.com创建的文件获取证书，将使用类似的 URL 访问

http​://www.example.com/.well-known/acme-challenge/2BHlJs9Qdk_8m6yRNzqEvwiVejyBsa8zXPpORGMIEz4

文件名是签名块的一部分，并且对于该请求是唯一的。稍后的请求将具有新的文件名和新的内容，因此无法预加载质询响应以试图绕过验证。无论如何，对于一个已知的域名来说，这一切都很好。当我们尝试获得证书时会发生什么*.mysub.example.com？证书服务器将尝试访问的 URL

http​://*.mysub.example.com/.well-known/acme-challenge/2BHlJs9Qdk_8m6yRNzqEVWiVejyBsa8zXPpORGMIEz4

那是行不通的。它甚至不会在 DNS 系统中查找，无论如何都不像预期的那样。在正常情况下，尝试在 DNS 中查找会收到一条NXDOMAIN错误消息，而当它确实返回某些内容时，它可能不是预期的。身份验证测试不能仅仅退回到一个级别，mysub.example.com因为请求的证书未涵盖该级别，并且可能也不在请求代理的控制之下。我可能能够为一个域或子域创建无限数量的子域，但无法将文件添加到父级本身。

向 DNS 添加通配符记录实际上与预期相反。只有当记录中没有匹配的域时，这样的记录才会匹配。mysub.example.com如果我使用正确的 DNS 记录创建 的子域，*.example.com则将不匹配。它也可以跨越记录类型。因此，即使存在通配符MX 记录，没有 MX 记录匹配的 CNAME 记录mysub.example.com仍将无法匹配对 MX 记录的请求。阅读RFC 1912可能很有趣，也很复杂。{这里是龙。}mysub

由于 DNS 中的通配符与证书中的通配符的含义相反，因此验证变得更加有趣。看看我可以注册几个域的可能性：

• david.jones.name
• james.jones.name
• sarah.jones.name
• mary.jones.name
• angelica.jones.name

然后我尝试为*.jones.name. 作为他们要求的验证，例如命名空间中的 4 个域名.jones.name。我可以提供 5 个可用的 4 个，并满足该测试。现在我有一个*.jones.name. 当 Jared Jones 得到jared.jones.name并且我使用我的*.jones.name证书进行 MitM 攻击时应该怎么做？

由于所有这些，他们无法自动验证通配符证书的请求是否来自负责该名称空间中现在或曾经存在的所有和任何子域的源。他们可以验证某人是否可以控制使用自动化工具，并且只要替换为可以验证的特定内容即可。一旦被替换为验证工具不起作用。验证通配符域命名空间权限的唯一方法是验证父域的所有权和请求方的身份。如果我拥有父域的所有权sub.example.comsubsub*example.com然后我可以在我选择的任何级别上自由地创建和控制任何东西作为子域。请注意，这里的“所有权”不同于“控制”，后者是由 ACME 协议验证的。

大多数情况下，在 LE 之外，证书是通过主机或注册商获得的，因此“身份”已经得到确认，并且所有权是已知的。如果我在 GoDaddy 注册并在 DigitalOcean 托管，他们都“知道”我是谁，并且对我拥有该域有相当程度的信心。即使他们自己不颁发证书，他们也可以处理请求，并向 CA 验证身份和所有权是否有效。这允许 CA 为请求的级别颁发通配符证书，即使它是我拥有的域的一两个级别，因为整个树属于我的所有权。

只需查看域的 whois 并了解该名称空间的规则通常足以确定所有权。然而，这是一个以人为中心的过程，并且无法通过任何合理的努力和可靠性水平实现自动化。更复杂的是，命名空间规则充其量是不一致的。例如，对于 .name gTLD，一些二级名称是可注册的，而另一些是保留的，三级名称是可注册的。这也适用于许多 ccTLD。我认为，有些 gTLD 始终是第 3 级注册，.pro就是一个例子。自动化过程如何“知道”是否*.smyther.name合法而不是*.david.smyther.name？

smith.name是保留的，人们必须在第三级注册，所以*.smith.name颁发一个不好的证书。OTOHsmyther.name不是保留的，因此*.smyther.name颁发 a 将是一个很好的证书。你可以通过whois系统查到。程序必须解析输出，输出总是会发生变化，因此对于自动化来说是不可靠的。我知道.namegTLD，但我也遇到过其他一些奇怪的、多变的规则使自动化成为可能，也许不是不可能，但不切实际。LE 是免费的，所以他们不能仅仅因为它很好就做所有的花里胡哨。

同样，关于 LE 颁发通配符证书，它归结为“自动化”。他们“可以”为这种情况和另一种情况建立条件。但是他们在哪里停止“调整”规则？他们在决策树中构建的分支越多，引入的故障点就越多。因为它是免费和自动的，所以通配符的价值较小。您可以一次获得涵盖 100 个域名的证书 (iirc)，那么为什么要使用通配符呢？他们的时间和精力最好花在对“更大的利益”更有价值的事情上，而不是构建异常和监控不断变化的条件。

是的，我知道在某些用例中通配符证书是必不可少的。在每个连接上获得一个新的、随机的和唯一的子域的移动应用程序不能使用 LE 证书。您每周可以请求多少证书是有限制的，因此他们无法在每次客户端连接时都获得新证书。技术上可能，但不会在 LE 上发生。但是，对于大多数此类边缘情况，还有其他选择。其中之一是在其他地方购买通配符证书。在许多涉及移动应用程序（甚至桌面应用程序）的情况下，还可以创建一个内部 CA，并将其添加到应用程序的信任数据库中，然后根据需要创建新的短期证书，并在内部签名。

Let's Encrypt 刚刚宣布他们将在 2018 年提供通配符证书：

通配符证书将通过我们即将推出的 ACME v2 API 端点免费提供。我们最初将仅支持通过 DNS 对通配符证书进行基域验证，但随着时间的推移可能会探索其他验证选项。我们鼓励人们在我们的社区论坛上提出有关通配符证书支持的任何问题。

来源：https ://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html

自 2018 年 3 月 13 日起，通配符支持现已上线！必要步骤的链接https://community.letsencrypt.org/t/acme-v2-production-environment-wildcards/55578

这是因为 Let's Encrypt 在发布密钥之前会验证您是否拥有该域。从技术上讲，他们可以颁发通配符证书，但这不是一个好主意。

想一想，如果您在 IBM 工作，并且在会计组中，您可以要求颁发给 awesomesauce.accounting.ibm.com 的域证书。但在他们颁发该证书之前，您需要通过输入特定的 DNS 条目或在网络服务器上托管一个证明您控制它的唯一文件或其他一些自动方式来证明您拥有该特定域。

为什么这是一个坏主意的例子。

如果您要求 *.ibm.com 的通配符证书，他们如何验证您拥有所有子域？他们不能通过自动化手段。如果他们确实颁发了通配符证书，您可以将其用作 ibm.com 上的任何子域，这可以被利用。使用通配符证书，您可以充当 password.ibm.com、ad.ibm.com 或任何其他关键站点，并解密访问该服务器的客户端流量。

并不是让我们加密 CANT 颁发的通配符证书，而是这是一个坏主意。他们在推广 HTTPS 方面做得非常出色，但发布通配符可能会导致很多附带损害。