卡关的不是工具，是验证方式

ACME 协议要求你证明「这个域名确实由你控制」，才会签发证书。证明的方式就是 challenge，目前主要有三种，分别要求你在不同的地方放上指定内容：网站的特定路径、DNS 的 TXT 记录，或 TLS 握手过程。

多数教程会直接给一行 Certbot 命令，默认用 HTTP-01。在单机、直接对外的架构上这确实能跑。但只要架构复杂一点——前面加了 CDN、后面有多台服务器、或需要通配符证书——HTTP-01 就会开始出问题，而错误信息通常不会直接告诉你「你该换一种验证方式」。

验证方式 运作原理 限制
HTTP-01 在网站特定路径放文件供 CA 读取 需开放 80 端口；CDN 或多节点易失败；不支持通配符
DNS-01 在域名下建立指定的 TXT 记录 唯一支持通配符；需 DNS API 权限与传播等待
TLS-ALPN-01 TLS 握手时返回特制证书 需直接掌控 443 端口；CDN 前置时不适用；不支持通配符
DNS-PERSIST-01 一次建立常设授权记录，之后免重复更新 IETF 草案阶段，生产可用性请以官方公告为准
三种 ACME 验证方式的运作原理与硬性限制。第四行是尚未进入生产的新方式。

下表把三种验证方式的原理与限制列清楚。第三栏才是选择的依据。

HTTP-01 会失败的三种情境

HTTP-01 要求 CA 能从公开网络读到你服务器上的特定文件。以下三种架构会让这个前提不成立：

  1. 服务在 CDN 后面 CA 连过来时会先碰到 CDN 节点，而验证文件放在源站。除非 CDN 配置了对 `/.well-known/acme-challenge/` 路径的回源穿透，否则 CA 读到的是 CDN 的缓存或 404。这是跨境团队最常遇到的状况，因为跨境服务几乎都会挂 CDN。
  2. 后端有多台服务器 负载均衡器会把 CA 的请求随机分到某一台，但验证文件只写在发起申请的那台上。命中率是 1/N，而且每次重试都可能落到不同机器。这种失败特别恼人，因为它是间歇性的——有时候会过，有时候不会。
  3. 80 端口不对外开放 基于安全策略关闭 80 端口、或服务本来就只在内网提供的环境，HTTP-01 完全无法运作。这也包含只想对特定来源开放的 API 域名。

DNS-01 的代价

DNS-01 解决了上面所有问题——它不需要 CA 连到你的服务器，只要能查到 DNS 记录就好。所以无论你在 CDN 后面、有几台机器、开不开 80 端口，都不影响。这也是为什么多节点架构几乎都会走 DNS-01。

但它有自己的成本。每次签发都要在 DNS 新增一笔 TXT 记录，代表自动化流程必须持有 **DNS 服务商的 API 凭证**。这些凭证要分发到会执行续签的每一台机器或 CI 环境，而 DNS 权限是高风险的——拿到它等同于能改你的域名指向。

值得注意的是，Let's Encrypt 在 2026 年 2 月提出了 **DNS-PERSIST-01**，改用一笔绑定特定 ACME 账户的**常设授权记录**，签发时不必再反复更新 DNS。这正好针对上述两个痛点。不过它目前仍是 IETF 草案，官方公告的生产上线时程为 2026 年第二季，实际是否已可用请以 Let's Encrypt 官方信息为准——同时要注意，授权变成常设之后，保护 ACME 账户密钥的重要性也随之提高。

通配符证书的硬限制

如果你需要 `*.example.com` 这种通配符证书，选择题直接结束：**只有 DNS-01 可以**。HTTP-01 与 TLS-ALPN-01 都无法签发通配符证书，这不是配置问题，是协议层面的限制。

这件事值得提早知道，因为它会反过来决定你的 DNS 供应商选择。如果你的域名注册商或 DNS 服务不提供 API，就无法自动化 DNS-01，也就拿不到自动续签的通配符证书——只能每次手动加 TXT 记录。在有效期已缩短到 200 天、未来将降至 47 天的情况下，手动处理不是可行的长期方案。

三个实作决策

实务上，选择可以收敛成三个问题：

一、你的架构前面有没有 CDN 或负载均衡？

有的话直接排除 HTTP-01 与 TLS-ALPN-01，走 DNS-01。硬要用 HTTP-01 也不是不行（配置 CDN 对验证路径穿透回源），但那等于多维护一条特例规则，而且 CDN 配置变动时容易被无意间破坏。

二、你需不需要通配符证书？

需要就只能 DNS-01，没有其他选项。如果子域名数量固定且不多，也可以考虑用 SAN 证书列举所有域名来避开通配符——但每新增一个子域名就要重新签发，这个取舍要依实际变动频率决定。

三、你的 DNS 供应商有没有 API？

这是走 DNS-01 的前提。挑选注册商或 DNS 服务时，API 支持应该是必要条件而非加分项。同时要规划凭证的存放方式——不要把 DNS API 密钥直接写在每台服务器的配置文件里，那会让证书自动化本身变成安全弱点。

开始前该确认的三件事

在动手配置自动化之前，先把这三项确认清楚：

  1. 列出所有需要证书的域名与子域名 这决定你需不需要通配符，也就决定了验证方式。事后才发现要加通配符，等于整套流程重做。
  2. 确认 DNS 供应商的 API 能力与权限粒度 除了有没有 API，也要看能不能发行「只能改特定域名 TXT 记录」的受限令牌。全权限密钥分发在多台机器上，风险太高。
  3. 确认验证与部署是分开的两件事 拿到证书只是第一步。证书还要送到每一个终止 TLS 的位置并生效，这部分 ACME 工具通常不管。动手前先想清楚部署那一段谁负责。

小结

证书自动化的难点从来不是安装 Certbot，而是在你的实际架构下选对验证方式。判断逻辑其实很短：**前面有 CDN 或需要通配符，就是 DNS-01**；而走 DNS-01 就必须先确保 DNS 供应商有 API，并妥善管理那把密钥。

如果你不想自己处理 DNS API 密钥的分发与多节点部署，我们的 SSL 证书自动化平台把验证与推送整合在同一个流程里——DNS 验证由平台完成，签发后直接推送到各 CDN 节点，省掉自行维护证书分发的环节。

参考资料