certbot 自动续期翻车实录：ACME 限流、staging 混用与证书链不完整的 5 个坑

一、现象：周五续期窗口，3 个域名里 1 个续不上，差点裸奔

上个月（2024-05）我们负责一批对外 HTTPS 域名，全部走 Let's Encrypt + certbot（版本 1.30.0）自动续期，由 systemd 的 certbot.timer 每 12 小时触发一次 certbot renew。

这本该是最省心的方案——Let's Encrypt 证书有效期只有 90 天，certbot 默认「到期前 30 天内才续」。结果周五凌晨 02:00 的续期窗口，3 个域名里 api.example.com（走 DNS-01 校验）连续失败，报错 rate limited；而 www.example.com（HTTP-01）正常续上了。等我白天发现时，api 的旧证书还剩 26 天，但当晚的 DNS 校验重试把 Let's Encrypt 的「3 小时 30 次 failed authorization」配额打满了，导致我手动补续的另一个子域也被 429 挡掉。

影响：当晚没有 502，因为旧证书还没过期；但按这个节奏，再过两三天就会直接「证书过期」，全站 HTTPS 挂掉。

二、根因：ACME 限流 + staging/production 混用 + 证书链不完整

拆开看，是三个坑叠在一起：

1. 限流是按「域名集合」算的，不是按「单张证书」算的。Let's Encrypt 的 production 速率限制里有一条 50 certificates per registered domain per week、100 certificates per unique set of domains per week，还有一条更坑的——5 identical certificates per week，且两次「完全相同」的签发之间要间隔 30 分钟。我当晚为了「救场」反复 renew，每次都触发一次 DNS-01 校验失败，累计把 3 小时 30 次 failed authorization 的配额烧光，后续合法续期也被 429 挡住。

2. staging 与 production 端点混用。我排查时为了「随便发一张试试」，把 certbot 的 server 指到了 staging（https://acme-staging-v02.api.letsencrypt.org/directory）。staging 不限流、随便发，但它签出来的证书浏览器不认。我一度以为「续上了」，其实是换了一张自签风的 staging 证书，差点把生产流量指过去。

3. 证书链不完整（incomplete intermediate）。Let's Encrypt 的 fullchain.pem = 你的服务器证书 + R3/R10 中间证书；chain.pem 只有中间证书。我有一台老网关只按 chain.pem 的方式挂载，结果 openssl s_client 验证报 OK（因为本地信任库恰好有中间证书），但部分老安卓 / 老 iOS 设备握手直接失败——典型的「本地能通、用户端报错」的诡异现象。

三、具体做法：可复现的排查与修复

1. 先看续期到底干了什么：

journalctl -u certbot.timer -u certbot.service --since "2024-05-17"
grep -n "Expiring in" /var/log/letsencrypt/letsencrypt.log

2. 用 staging 安全地演练（不烧生产配额），校验流程通了再切 production：

certbot certonly --dns-aliyun -d api.example.com \
  --server https://acme-staging-v02.api.letsencrypt.org/directory \
  --dry-run -v

3. 切回 production 正式续（--webroot 路径必须能被 ACME 回源命中 /.well-known/acme-challenge/）：

certbot renew --deploy-hook "systemctl reload nginx" -v

4. 验证证书链是否完整（关键：确认 s: 那行是 LE 的中间证书，而不是只有叶子证书）：

openssl s_client -connect api.example.com:443 -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer

5. 给生产加一道「续期失败即告警」的兜底，别靠人肉发现：

# renew 后检查剩余天数，< 20 天就告警
openssl x509 -in /etc/letsencrypt/live/api.example.com/cert.pem -noout -enddate

四、踩过的坑 & 反直觉

• 反直觉：openssl s_client 本地验证通过 ≠ 所有用户端都通。证书链不完整时，只有「本地信任库恰好有中间证书」的机器能通，移动端最容易翻车。一定发 fullchain.pem。
• 坑：identical certificate 的 5 次/周 + 30 分钟间隔，意味着「手动反复重试」不仅救不了场，反而把配额烧光。救场应先切 staging 验证，再等配额窗口。
• 坑：DNS-01 校验依赖解析生效，若域名 TTL 设成 3600s，ACME 侧最长要等约 1 小时才认，看起来像「卡死」，其实是 propagation 没到。

五、结论与可复用清单

Let's Encrypt 省心在「免费 + 自动化」，但它的限流模型是按域名集合算的，一旦某台机器反复失败，会连累同集合下的其它域名。可复用清单：

1. 演练一律走 staging，确认 --dry-run 全绿再上 production；
2. 只发 fullchain.pem，别只给 chain.pem；
3. DNS-01 域名把 TTL 降到 300s 以内再申请；
4. certbot renew 加 --deploy-hook 自动 reload，并加「剩余 < 20 天」告警；
5. 记住 4 条配额：50/注册域名/周、100/域名集合/周、5 identical/周（间隔 30 分钟）、30 failed authz/域名/3 小时。