证书自动续期突然失败：ACME 的三种验证方式和一份排查顺序
证
证书自动续期这种事，稳定得让人忘记它存在，直到某天早上收到过期提醒。慌张之下重装客户端、换目录、清缓存，一轮操作下来还是失败——因为真正的病因不在这几处。
图片来源：网络，版权归原作者所有，侵权请联系删除
三种验证方式，卡点完全不同
| 方式 | 在哪里验证 | 能签通配符吗 | 主要卡点 |
|---|---|---|---|
| HTTP-01 | 80 端口下的 .well-known/acme-challenge | 不能 | 80 端口不通、多台机器文件不同步 |
| DNS-01 | _acme-challenge 的 TXT 记录 | 可以 | DNS 接口、传播延迟、旧记录堆积 |
| TLS-ALPN-01 | 443 端口的 TLS 握手 | 不能 | 需要终结点支持，客户端覆盖面窄 |
通配符只能用 DNS-01，这是协议规定，没有变通。多台机器负载同一个域名时，HTTP-01 要求那个验证文件在每一台上都能取到，漏一台就是间歇性失败——这种失败最难查，因为重试有时候会成功。
HTTP-01 只走 80 端口，而且允许跟随重定向，最多十跳，但只接受跳转到 80 或 443 端口。重定向目标上的证书是否有效它不管，所以证书已经过期的情况下重定向到 https 依然能验证通过。
排查顺序：先查别人改了什么
经验是，跑了很久突然失败，往往是环境里某个东西被改了，而不是续期脚本坏了。按这个顺序查：
- CAA 记录。发证机构每次签发前都会查，谁给这个域名授权了。别人加了一条指向别家的 CAA，你的续期立刻失败，而你的服务器一点没变。这一条解释了大多数「莫名其妙」的失败。
- 80 端口和它的重定向规则。安全组改了、nginx 配置被覆盖、新加了强制跳转规则把验证路径也跳走了，都会让验证文件取不到。
- DNS 传播。用 DNS-01 的话，接口写进去了不等于立刻生效，有些服务商要等挺久。客户端里那个等待时间调长一点，或者换用能查询生效状态的服务商。
- 旧的 TXT 记录。反复重试会留下很多条 _acme-challenge 记录，响应太大可能被拒，定期清一遍。
多视角校验这件事
现在的验证不是从一个地方发起的，而是从多个网络位置同时查，要求结果一致。这挡住了能影响局部路由或 DNS 的攻击，但也带来一个副作用：你本地测通了不代表验证能通过。
地区性的防火墙、按来源返回不同解析结果的智能 DNS、anycast 配置不一致，都会造成「我这边明明是好的」这种失败。遇到这种情况，最快的办法是用外部工具从别的地方查一次解析结果。
限流会让你越试越糟
失败是计入配额的。常见的几条：每个注册域名每周五十张证书，完全相同的域名组合每周五张，失败的验证在一小时内按账户和主机名各有上限。连续重试会把配额吃光，然后连正常的签发也做不了。
所以调试要对着测试环境做，配额高很多，签出来的证书不被浏览器信任但流程一样。确认流程通了再切回正式环境。
凭据放哪儿
用 DNS-01 就要给客户端 DNS 的操作权限。把完整的 DNS API 凭据放在 web 服务器上，等于给入侵者一把开整个域名的钥匙。更稳的做法是用权限收窄的凭据，或者把验证放在另一台机器上做，签完再把证书同步过来。
让失败早点暴露
别依赖证书过期提醒。在监控系统里加一条：每天读一次证书剩余天数，低于三十天就告警。三十天够你从容排查，也能扛过限流导致的等待。另外把续期的执行日志留下来，失败时那几行输出比任何猜测都有用。