ACME 证书自动化：三种域名验证原理、续期配置与常见误区

给站点上 HTTPS，手工流程是生成 CSR、提交、下载、装进服务器，到期前再走一遍。ACME 把这几步压成一条可自动执行的协议：客户端向 CA 证明域名控制权，换取证书，并在到期前自行续期。下面讲清三种验证方式的原理、签发与续期的配置步骤，以及运维里反复踩到的误区。

ACME 解决的是什么问题

ACME 全称 Automatic Certificate Management Environment，技术规范是 IETF 的 RFC 8555。它规定的是一组 JSON 接口：注册账户、提交订单、应答挑战、下载证书、发起吊销。

这些动作原本靠人工完成，验证邮件、粘贴 CSR、下载证书都是手工环节。手工环节一多，证书就容易过期。缩短有效期可以降低密钥泄露和错签的影响面，但前提是续期必须自动化。

所以 ACME 的价值不在于证书不要钱，而在于把域名验证做成了可编程的挑战应答。客户端只要能证明自己控制这个域名，就能在无人值守的情况下反复换新证书。

三种域名验证方式的原理与边界

RFC 8555 本身定义了 http-01 和 dns-01，RFC 8737 补充了 tls-alpn-01。三者都是让 CA 从外部确认你确实控制这个域名，但通道不同，适用场景差别很大。

http-01 是默认选择。客户端把 token 写成文件放到网站的固定路径下，CA 再从多个网络位置去取。Let's Encrypt 的文档说明了细节：它会跟随重定向，上限 10 次，只接受指向 80 或 443 端口的跳转，且不校验跳转目标的证书，因为这个挑战本来就是为了给还没有证书的站点签发。

dns-01 适合两类情况：要签通配符证书，或者站点不直接暴露在公网。记录放在 _acme-challenge 前缀下，也可以用 CNAME 把校验委派到别的区域。代价是必须拿到 DNS 服务商的 API 凭证，而把全权限凭证放在 Web 服务器上，机器一旦被入侵，影响面会放大。更稳的做法是给 API 凭证收窄权限，或者把 DNS 验证放在单独机器上做，再把证书同步过去。

tls-alpn-01 在 443 端口做纯 TLS 层校验。客户端临时出示一张自签证书，SAN 里是待验证域名，acmeIdentifier 扩展里是授权的 SHA-256 摘要，CA 用 acme-tls/1 这个 ALPN 名连上来逐项核对。它要求 TLS 1.2 以上，主要面向做 TLS 终结的反向代理和大型主机商，普通站点用不到。

从签发到自动续期的完整步骤

以 certbot 加 nginx 为例，一条路径可以概括成下面几步。换成 acme.sh、lego 或 Caddy 内置的 ACME，逻辑一致，差的只是配置文件放在哪。

1. 让域名解析指向服务器，确认 80 端口对公网可达，nginx 已经能正常响应这个域名。
2. 安装客户端。Debian 或 Ubuntu 上是 apt install certbot python3-certbot-nginx；也可以按官方说明用 snap 安装并软链到 PATH，注意别让两套安装并存。
3. 首次签发。certbot --nginx -d example.com -d www.example.com 会顺手改配置并 reload；想自己管配置就用 certonly 子命令。
4. 先做一次演练：certbot renew --dry-run。它会走完整验证流程，但不消耗正式额度。
5. 确认定时器在跑：systemctl list-timers 里能看到 certbot。装包时通常已经带上 systemd timer，一天跑两次，只有接近到期才真正续。
6. 补一个 reload 钩子。把 nginx -t 加 systemctl reload nginx 写进 /etc/letsencrypt/renewal-hooks/deploy/ 下的脚本，并加执行权限。
7. 从外部核对结果：在另一台机器上跑 openssl s_client，看实际返回的到期时间和签发者。

第六步经常被漏掉。nginx 启动时把证书读进内存，磁盘上换了文件它不会自动重读，续期日志写着成功、线上仍在发旧证书的情况就是这么来的。

有效期在缩短，续期节奏要跟着改

CA/Browser Forum 的 SC-081v3 决议在 2025 年 4 月通过，给出了一张逐步缩短的时间表：公开可信 TLS 证书的有效期上限从 398 天降到 200 天（2026 年 3 月 15 日起），再降到 100 天（2027 年 3 月 15 日起），2029 年 3 月 15 日起降到 47 天。同一份规范还把 SAN 验证数据的复用期从 398 天压到 10 天，意味着续期时重复使用旧验证结果的空间越来越小。

Let's Encrypt 走得更靠前。它在 2025 年 1 月公布了短期证书方案，同年 2 月签发了一张有效期 6 天的证书，通过 ACME 的证书 profile 机制选择 shortlived 配置。这类证书不带 OCSP 和 CRL 地址，实际含义是明说一件事：吊销这条路不够可靠，靠快速过期兜底。

节奏变快之后有两件事要跟着调。一是续期触发点，按剩余寿命的三分之一来算比较稳妥，90 天证书在剩 30 天时动手，6 天证书就要在剩 2 天左右动手，客户端至少每天跑一次。二是监控点，别只看证书文件的时间戳，要从外部连上去读实际返回的那张证书，SNI 参数记得带上，否则拿到的是默认站点证书。

常见误区、适用人群与上手建议

五个高频误区

• 以为续期成功就等于生效。不 reload 或 restart，旧证书会一直留在内存里。
• 只装叶子证书。缺中间证书时部分客户端会报链不完整，配置里该指向的是 fullchain 文件。
• 拿正式环境试错。反复删配置重装会撞上同一标识符集合 7 天 5 张的限制，调试请切 staging。
• 以为所有续期都不占额度。走 ARI 的续期确实不受速率限制，但旧式的同集合续期仍受授权失败次数和同集合上限约束。
• 把全权限 DNS API 凭证放在 Web 服务器上，且长期不轮换。

几个值得记住的数字

按 Let's Encrypt 的速率限制文档（2026 年 8 月更新）：每个注册域 7 天内 50 张证书，同一标识符集合 7 天内 5 张，单账户 3 小时内 300 个新订单，单 IP 3 小时内 10 个新账户，单证书最多 100 个标识符。授权失败的上限是每个标识符每账户每小时 5 次，连续失败过多会把该标识符暂停签发，届时只能通过自助门户解封。

适合谁，从哪一步开始

只要你有域名和一台能对外提供 80 或 443 的机器，自动化就值得做。个人站点用 certbot 的 nginx 插件更省事；域名多、实例多的场景更适合 Caddy 或 cert-manager 这类把续期做进运行时的工具。已有面板接管的，先确认面板自己会不会续期，别在上面再叠一层客户端，两套系统抢同一个域名很容易互相覆盖。

监控层面也要分开看。轻量的自托管监控工具擅长看主机负载和服务存活，证书到期仍建议单独做一次外部检查，因为续期失败往往不会有任何错误日志。

建议的上手顺序是：先用 dry-run 跑通验证，再补 deploy hook，然后从外部机器确认实际返回的证书，把这套动作固化成例行检查。剩下的交给定时器。

相关阅读

• 已有面板在建站阶段接管证书，可以先看 宝塔面板建站流程，确认面板的 SSL 模块会不会自己续。
• 用自托管平台部署多个站点时，Coolify 的部署方式与局限里提到它自动处理证书，理解它的边界能避免重复签发。
• 协议类知识想换个角度，可以对照 MCP 协议的入门梳理，两者都是"客户端向服务端证明身份"的思路。
• 服务器侧的存活监控可以看 Beszel 的 hub 加 agent 架构，但证书到期要另做检查。