Let's Encrypt 将默认签发 64 天证书，旧版 acme.sh 续期安排出错

2026-10-15 12 分钟阅读 DevOps Daily Team

Let's Encrypt 转向 64 天证书：你的 ACME 客户端到底什么时候续期？

Let's Encrypt 将从 2027 年 2 月 10 日起默认签发 64 天证书（原来是 90 天），并将在 2028 年进一步缩短到 45 天。其 staging 环境已于 2026 年 10 月 14 日切换，我们提前布置了一个监视器等着它：第一张 64 天证书在 UTC 21:35 抵达。我们用五种 ACME 客户端安装分别申请了 64 天 staging 证书，记录下各自何时续期，并在 45 天和 90 天期限下做了同样的测试作为对照。使用 ARI 的客户端在 64 天证书的第 42 或 43 天续期或安排了续期，与 45 天和 90 天时一样，都落在证书生命周期的三分之二处。出问题的是旧版 acme.sh：3.0.7 版在默认配置下把 64 天证书的续期安排在第 59 天，也就是到期前五天；而使用 --days 80 时安排在第 79 天，也就是到期后十五天。升级到 3.1.6 后，下一次检查时该计划被移到了第 42 天。

对于 64 天 staging 证书，Let's Encrypt 的 ARI 端点建议在第 42.04 天到 43.32 天之间续期，即生命周期的 65.7% 到 67.7%。我们在 45 天和 90 天期限下测到了相同的比例。这大约是在到期前 21 天。

certbot 5.8 在这个窗口内完成了续期（它每次运行都会在窗口内随机选一个时间点），acme.sh 3.1.6 安排在第 42.16 天，lego 5.5.2 允许从第 42.67 天起续期。这些配置已经为更短的有效期做好了准备。

certbot 2.9 是我们 Ubuntu 24.04 机器上 apt 安装的版本，它不使用 ARI，会在到期前 30 天进入应续期状态：即 64 天中的第 34 天。偏早，但安全。

acme.sh 3.0.7 把下一次续期安排在签发时间 + --days - 1 天，完全不校验到期日期。默认值 60 给出的是 64 天中的第 59.04 天，--days 80 则给出第 79.04 天。我们扫描过的从 3.0.7 到 3.1.2 的每个 acme.sh 标签，默认值都是 60。

正如 Let's Encrypt 自己建议的那样，请搜索你的 cron 任务、包装脚本和监控配置中硬编码的 60、80 和 83，同时别忘了检查你的续期定时器、challenge 路径和 deploy hook。

前置条件

一台使用 certbot、acme.sh 或 lego 续期证书的服务器 可用的 Shell 访问权限，用于检查客户端版本及其存储的续期设置 如需复现测试：一台端口 80 可从外部访问的一次性 VM，以及 faketime 我们运行过的一切、以及每一个输出文件，都在仓库里：

摘自 Let's Encrypt 2026 年 10 月 7 日的公告：

公告中的建议很简短：如果你的续期是自动化的，且客户端支持 ARI，那基本就没问题了；如果不支持，就在大约三分之二生命周期处续期，并在 cron 任务、包装脚本和 runbook 中查找 83、80 或 60 这类硬编码值。我们想看看哪些客户端真正遵循了这一点，以及不遵循的客户端会怎样。

在一台一次性 Ubuntu 24.04 droplet 上，我们并排安装了五个客户端版本：来自 apt 的 certbot 2.9.0、来自 snap 的 certbot 5.8.0、来自上游仓库的 acme.sh 3.0.7 和 3.1.6，以及 lego 5.5.2。它们向 Let's Encrypt staging 环境申请了真实证书，使用解析到该 droplet 的 sslip.io 域名，分别测试三种有效期。当某个客户端无法申请指定有效期时，我们使用复制的状态文件或其源码来分析：

天数从每张证书的 notBefore 时间算起，Let's Encrypt 将其设定在签发时间前约一小时。以下是 certbot 2.9 在 64 天证书上的探测记录：

第 33.96 天时未到期，第 34.08 天时已续期：阈值就在两者之间，与 64 天到期前 30 天一致。

ARI 客户端：窗口本身就够了

ARI 窗口在三种期限下都从生命周期的 65.7% 开启、到 67.7% 关闭：64 天的第 42.04 至 43.32 天，45 天的第 29.56 至 30.46 天，以及 90 天的第 59.11 至 60.91 天。对于 64 天证书，这大约是在到期前 21 到 22 天。遵循该窗口的客户端在 2028 年切换到 45 天时也无需任何改动。

在等待期间，我们根据 45 天和 90 天的运行结果预测了 64 天那一列，并在 UTC 21:32 提交了预测（仓库中的 commit f909cfc）。我们在 UTC 21:35 发出的下一次请求，返回了第一张 64 天证书。表格中每一个 64 天的结果都与该预测一致（results/projection-64.txt 和 results/measured-64.txt）。

certbot 5.8 不会在某个固定时刻续期。每次运行时，它都会请求窗口，在窗口内随机选一个时间点，如果该时间点已经过去就续期。其源码（acme/client.py）如下：

delta_seconds = (end - start).total_seconds()
random_seconds = random.uniform(0, delta_seconds)
random_time = start + datetime.timedelta(seconds=random_seconds)

因此，在窗口进行到三分之一时的某次运行，大约有三分之一的概率会续期。以下是我们 64 天的探测记录，每次都从同一状态的副本重新开始：

第 1010 小时（第 42.08 天，2026-11-25 22:37:12 UTC）：未到期 第 1014 小时（第 42.25 天，2026-11-26 02:37:12 UTC）：未到期 第 1020 小时（第 42.50 天，2026-11-26 08:37:12 UTC）：已续期 第 1030 小时（第 42.92 天，2026-11-26 18:37:12 UTC）：未到期

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）