通配符证书必须用 DNS-01 吗？HTTP-01 与 DNS-01 在真实运维里的取舍

有同事问过一个很典型的问题：「我就想给 api.example.com 续个证书，为什么非要我配 DNS API？」答案是——不必须。但如果你要的是 *.example.com，那就没得选了。HTTP-01 和 DNS-01 的分界线其实就划在这里，剩下的大多是工程上的取舍。

HTTP-01：够用，但只在你控制 Web 入口时够用

HTTP-01 的逻辑很直白：CA 让你在某域名下放一个随机文件，路径固定是 /.well-known/acme-challenge/，它通过 80 端口来取。能取到，就证明你控制这个域名指向的服务器。

好处是零依赖——不需要 DNS 厂商的 API 凭据，不需要等解析生效，验证几秒就完。对单域名、少数几个域名的场景，这是最省事的路。

但边界也很硬：

• 签不了通配符。 RFC 8555 的规定，通配符必须走 DNS-01，没有商量余地。
• 80 端口必须能从公网到达。 有些环境 80 被防火墙挡了，或者前面挂着 CDN、负载均衡，challenge 文件根本递不到源站。
• 多节点部署时麻烦。 域名解析到五台机器，CA 随机打一台，你得保证文件在五台都在，或者用反代把 challenge 请求统一转发到一个地方。这个坑不少人都踩过：本地验证好好的，一上 LB 就随机失败。

DNS-01：麻烦一次，之后都顺

DNS-01 是往 _acme-challenge.example.com 写一条 TXT 记录。它不关心你的 Web 服务在哪、80 通不通，只看 DNS。所以它能签通配符，也能给根本不暴露 HTTP 的内网服务签证书（只要域名 DNS 在公网可解析）。

代价是自动化必须能改 DNS 记录。如果你的 DNS 服务商有 API，用对应插件写 TXT、等传播、签完再删，流程可以全自动。注意两点：

• TXT 记录传播有延迟，签发脚本里通常要等几十秒并主动轮询确认，急性子直接提交容易被 CA 拒。
• DNS API 凭据权限往往很大（能改整个 zone），泄露比一张证书严重得多。别把这个凭据随便扔在每台跑证书的机器上。

后一个问题有个干净的解法：CNAME 委托。把 _acme-challenge.example.com CNAME 到一个专门用于验证的子域（比如托管在另一个 zone 里），ACME 客户端只需要那个子域的写权限。主 zone 的凭据完全不落地，爆炸半径小很多。

怎么选

按域名结构看，基本一锤定音：

• 少量固定子域、80 端口可达 → HTTP-01，别给自己加戏。
• 需要通配符、服务不暴露 80、或在 CDN/LB 后面 → DNS-01，优先用 CNAME 委托隔离凭据。
• 混合场景也常见：主站用 HTTP-01，内部泛域名用 DNS-01，两条腿走路没有问题。

在 CertbotX 中实践

CertbotX 的 DNS-01 流程支持 CNAME 委托：把 _acme-challenge 指向委托子域后，ACME 自动签发和到期前重新签发都走这条通道，主 zone 凭据不参与。签发完成后可以自动把证书部署到 Agent、EdgeOne 或其他 CDN，每次部署有记录可查，出问题能回溯是哪次部署换了哪张证书——通配符证书往往被多处复用，这条审计链比单域名场景更重要。

延伸阅读：

• RFC 8555（ACME 协议）中关于验证类型的定义
• Let's Encrypt 官方文档：Challenge Types