几十个站点的 HTTPS 证书，如何用 ACME 自动续期彻底告别"忘记续费"

证书到期这种事，不是忘了，而是"以为别人记得"。站点多到几十个以后，靠日历、表格、群消息提醒，本质是拿人肉当定时任务——而人肉是最不可靠的守护进程。真正靠谱的办法只有一个：让续期这件事从头到尾不需要人参与。

先确认前提条件

动手之前，先盘清楚你的环境，这决定了选哪条路：

• 这几十个站点是否集中在少数几个域名下？如果是，一张通配符证书（*.example.com）能省掉大量管理工作。
• 域名 DNS 托管在哪里？DNS 服务商是否有 API？这决定你能不能自动化 DNS-01 验证。
• 证书部署到哪里？是自己管理的 Nginx、边缘节点，还是 CDN？

核心思路：ACME 协议

Let's Encrypt 等 CA 都支持 ACME 协议（RFC 8555）。流程是：客户端向 CA 证明你控制这个域名，CA 签发证书；续期就是把这个流程再跑一遍。只要客户端能定期自动执行，"忘记续费"这个问题就不存在了。

验证方式有两种，按场景选：

HTTP-01：CA 访问你站点上的某个文件来验证控制权。前提是 80 端口可达、域名已指向服务器。简单直接，但签不了通配符证书，而且在多机部署时每一台都得能响应验证请求。

DNS-01：在 DNS 里加一条 TXT 记录完成验证。能签通配符证书，不要求服务器暴露端口，站点分散在多台机器时尤其合适。前提是你的 DNS 服务商支持 API 自动改记录——这条不满足，自动化就断了。

站点数量多、分布散的运维环境，DNS-01 通常是更省心的选择。

关键一步：续期只是开始，部署才是坑

很多人把 certbot 定时任务一配就觉得完事了，结果证书在服务器 A 上续好了，实际提供服务的却是服务器 B、C 和 CDN——A 上证书崭新，用户看到的还是过期证书。

所以完整的自动化链条是三段：

1. 签发/续期：ACME 客户端定期检查，到期前自动重新签发。
2. 部署：新证书签发后，自动推送到所有真正用它的地方——Web 服务器、负载均衡、CDN、边缘节点。
3. 验证与记录：部署完要确认实际生效，并留下记录，出问题能追溯。

第三段经常被忽略。最低成本的验证是部署后用脚本对每个域名检查一遍证书有效期：

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates

把几十个域名写成列表循环跑一遍，输出和预期不符就告警。这样即使自动化链路某处断了，你也能在用户发现之前知道。

在 CertbotX 中实践

如果不想再自己拼接脚本，CertbotX 把这条链路做成了内置流程：通过 DNS-01 的 CNAME 委托方式完成验证（把 _acme-challenge 记录委托给一个专门用于验证的域名，主 DNS 不用开放 API 权限），证书到期前自动走 ACME 重新签发，签发后自动部署到 Agent 所在的服务器、EdgeOne 或 CDN。每次部署都有记录可查，审计时能看清哪张证书、什么时候、发到了哪里。对几十上百个站点的场景，重点是把所有域名纳入同一个管理面，而不是每处各管各的。

上线前的检查清单

• 每个域名跑一遍签发流程，确认验证方式真实可行，别假设 DNS API 权限没问题。
• 部署后逐个域名用上面的 openssl s_client 方法核对生效情况，而不是只看工具报的成功状态。
• 留一个独立的告警：任何域名剩余有效期低于某个阈值就通知到人。自动化是主力，告警是保险丝，两者都别省。
• 通配符证书和单域名证书不要混用同一套部署脚本而没人核对，推送目标不一致时容易漏。

做完这些，"续费 HTTPS"就从一项要人记住的工作，变成了一套会自己运转、出问题会喊的系统。剩下的精力，留给真正需要人的事。

---

参考文档：

• ACME 协议规范 RFC 8555 — 了解自动签发与续期的协议细节
• Let's Encrypt 文档 — 签发频率限制、验证方式等实务说明