我正在使用ngrok来演示 IIS/Windows 上的 ACME 协议。但是，此服务更喜欢 CNAME 而不是 A 记录。
在调试交互时，似乎 ACME 只允许 A 记录。这种行为的安全原理是什么？有什么选择？
这里的错误信息：
{
"type": "http-01",
"status": "invalid",
"error": {
"type": "urn:acme:error:connection",
"detail": "DNS problem: SERVFAIL looking up A for dev.server.com",
"status": 400
},
sebastian nielsen 的回答是错误的，因为安全漏洞位于一个名为 startencrypt 的无关服务中。Letsencrypt 不支持 CNAME 记录的暗示也是不正确的，正如该线程和其他几个 Letsencrypt 版主向人们保证他们确实支持 CNAME 记录所验证的那样。事实上，我刚刚通过使用 CNAME 记录指向 Azure VM 的子域的验证。
certbot 给出的错误消息，当出现问题时非常具有误导性，我在官方文档中找不到关于 CNAME 支持的任何内容，导致所有这些混乱。
这样做的原因是，如果您允许 CNAME，它可以为您不拥有的网站生成证书。
有一个安全漏洞，您可以在其中设置自己的 CNAME，例如“yoursite.com CNAME google.com”，然后能够为 google.com 生成证书。重定向也存在同样的问题，您可以在其中设置重定向并导致颁发未经授权的证书。
然而，他们并没有通过在偶然发现 CNAME/重定向后重新验证地址来修复实际漏洞，而是简单地阻止了重定向和 CNAME。