Certbot: 需要通配符证书支持 | 与 CA 的利益冲突？

@HLFH ，我们锁定了#66，因为我们不必要地意识到对通配符证书的需求。 尽管锁定了问题，但我可以向您保证，我们并没有忘记对此功能的需求。

此存储库适用于遵循不允许通配符证书的ACME 协议的 Let's Encrypt 客户端。 由于添加此功能超出了客户端的范围，因此我将关闭此问题。 请随时跟进 ACME 的 IETF 工作组。 您可以在他们的github 页面上找到更多信息。

有人能解释一下ACME 第 6.6 节在这种情况下的含义吗：

由服务器的本地策略决定哪些名称是
考虑到服务器的授权，在证书中可接受
与客户的帐户密钥相关联。 服务器可能会考虑一个
授权通配符域的客户端，如果它被授权用于
基础域名（不带“*”标签）。

PR 14甚至还没有合并更清楚地表达了这一点。

据我所知，这将允许 LE 为域（例如：example.com）授权客户端，然后从 ACME 规范的角度颁发通配符证书（例如：*.example.com）。

在我看来，缺乏通配符支持与服务器的本地策略有关。 如果是这样，请明确说明 LE 的政策（当前）反对颁发通配符认证并停止指责 ACME WG。 :)

如果我错了，请提前感谢您的澄清。 :)

@bmw对此有何想法？ 也许将更新推送到 #66 甚至解锁它以便人们知道发生了什么？ 我也在 ping 分别锁定和关闭 #66 的@jmhodges和@bdaehlie 。

我只是自己查看了规范以查看通配符是否有任何变动，并看到了@MichaelHierweck提到的第 6.5 节中）。

特别是考虑到这个项目不再只是letsencrypt ，而是现在certbot应该完全支持该协议，而不受不遵守规范的单个提供商的限制。 发行政策很难，实施规范则不然。 我认为如果有人试图获取 letencrypt 发布的通配符，certbot 只会抛出某种错误消息。

就个人而言，我希望在客户端支持这一点并将责任_正确地_推到 LE 服务器/ca 端，促使他们允许使用通配符，因为这将使我正在处理的一些项目变得更加容易。

就个人而言，我认为通过将人们指向https://community.letsencrypt.org 可以正确解决 #66

如果客户端被授权使用底层域名（没有“*”标签），则服务器可以考虑授权使用通配符域的客户端。

不是新的，可以追溯到letsencrypt/acme-spec#166。 当我说 ACME 规范中不允许这样做时，我是不正确的。

话虽如此，我创建了 #3233 来跟踪允许用户在客户端请求通配符证书的问题。