把证书续期从「到期前N天」改成「寿命2/3」：对照Let's Encrypt 64天预案

目标：在 2027 年 2 月 10 日 Let's Encrypt 默认改为 64 天证书之前，确认你的 ACME 续期不会因为写死「到期前 N 天」而踩空。下面步骤直接依据官方 2026-10-07 博文，可照着核对生产与预发。

准备工作

• 一台已经在用 Let's Encrypt 的站点，最好另有暂存/预发

• 能改 cron、systemd timer 或 CI 续期脚本的权限

• 记下当前证书的 notBefore / notAfter，方便对比

• 官方已在 2026-10-14 把暂存环境切到 64 天，适合先试

操作步骤

1、确认客户端是否支持 ARI

做什么：打开你正在用的 ACME 客户端文档，查找 ACME Renewal Info（ARI）支持说明与开关。
为什么：支持 ARI 时，服务器会告知合适续期窗口，通常不必再手写固定天数；这是官方最省心的路径。
如何确认：文档明确写了 ARI；或续期日志里出现遵循 ARI/renewal info 的记录，而不是只打印「距到期还有 X 天」。

2、把写死的续期天数搜出来

做什么：在续期相关目录执行搜索，重点找 83、80、60、30 这类硬编码，以及「expire - 30d」一类表达式。
为什么：官方点名硬编码距到期天数的脚本，在寿命从 90 天收到 64 天后，容易续得过晚或行为怪异。
如何确认：列出每一处命中，并在变更单标注「保留 / 修改 / 删除」；没有命中也要写明「已全库检索无硬编码」。

3、改成约寿命的三分之二，并补上重载与告警

做什么：将触发条件改为大约证书寿命的 2/3（64 天大约在第 42 天前后），续期成功后执行 web 服务器或网关 reload；同时给失败路径加告警。
为什么：官方明确建议用「约三分之二寿命」为 64 天乃至未来 45 天做准备；只更新文件不重载，线上仍可能握着旧证。
如何确认：在暂存跑通一次续期，新证书 notAfter 符合预期，对外 HTTPS 握手看到的是新证；故意制造一次失败能收到告警。

4、检查是否依赖过长的授权复用

做什么：确认自定义封装没有把「30 天内复用旧授权」当成硬依赖；按文档把缓存 TTL 缩短，或改为每次完整验证。
为什么：授权复用期将从 30 天降到 10 天，2028 年还会更短；依赖长复用会在边界失败。
如何确认：预发环境按新 TTL 完成一次完整签发；日志里验证步骤符合预期。

注意事项

• 费率限制不因寿命变短而单独收紧，但失败重试仍要有退避

• 生产变更前先在暂存验证；不要在流量高峰首次改脚本

说明：步骤基于 Let's Encrypt 2026-10-07 博文，于 2026-10-24 核对。

来源

[1] Sarah Gran，Let's Encrypt，《64-Day Certificate Lifetimes Coming Feb 2027》，2026-10-07，https://letsencrypt.org/2026/10/07/64-day-certs

#Let'sEncrypt #ACME #续期 #DevOps #证书自动化