- 引言 — 第一个截止日期已经过去了
- SC-081v3 实际定下的时间表 — 原文的两张表
- 投票结果说明了什么 — 2019 年与 2025 年
- Let's Encrypt 的实际过渡日期 — 90 → 64 → 45
- 6 天证书与 IP 证书 — 已经正式可用
- 不要把续期时机写死 — ACME ARI(RFC 9773)
- 还没到来的部分 — DNS-PERSIST-01 的现状
- 那么，该准备些什么
- 结语
- 参考资料
引言 — 第一个截止日期已经过去了
2026 年 3 月 15 日，公开信任(publicly-trusted)TLS 证书的最长有效期从 398 天降到了 200 天。写这篇文章的时候，这已经是四个月前的事了。如果你的团队一直靠一年一次的手动续期撑着，那你大概在今年的续期节点上已经体会到了；如果还没体会到，那就等你现在用的证书到期那天，一定会体会到。
而这只是开始。2025 年 4 月 CA/B Forum 通过的投票 SC-081v3 敲定了一份时间表，要在 2029 年 3 月之前把最长有效期降到 47 天。可是关于这个话题，各家转述文章给出的日期总有些许出入。所以本文先从投票文本和 TLS Baseline Requirements(BR)原文里直接核实分阶段的日期，然后再梳理 Let's Encrypt 公布的实际过渡日期，以及在这份时间表下能活下来的工具 — ACME 配置文件(profile)、6 天短期证书、ARI(RFC 9773)、DNS-PERSIST-01 — 并附上截至目前的真实支持状况。
顺带一提，证书领域另一条重大主线 — 后量子迁移，我在为什么 PQ 证书还没来一篇里另行讨论过。两条线是相互咬合的 — 有效期越短，算法替换也就越快。本文只谈有效期和自动化这一条线。
SC-081v3 实际定下的时间表 — 原文的两张表
这是 BR 6.3.2 节里最长有效期的时间表。我核对过现行 BR(v2.2.8，2026-06-16)，投票通过时的文字原封不动地保留在其中。
| 以签发日期为准 | 在此日期之前 | 最长有效期 |
|---|---|---|
| — | 2026-03-15 | 398 天 |
| 自 2026-03-15 起 | 2027-03-15 | 200 天 |
| 自 2027-03-15 起 | 2029-03-15 | 100 天 |
| 自 2029-03-15 起 | — | 47 天 |
每个阶段都附带一条低一天的 SHOULD NOT 上限(397、199、99、46 天)。BR 把一天定义为 86,400 秒，并明确规定哪怕只超过一秒，也要多算一天。因此才有了「不应该(SHOULD NOT)卡着上限发证」这句话 — 后文会提到的 Let's Encrypt 的 45 天这个数字，正是从这里来的。
而下面这张表，是同一次投票修订的 4.2.1 节中，域名/IP 验证数据复用的时间表。
| 以签发日期为准 | 在此日期之前 | 验证数据复用上限 |
|---|---|---|
| — | 2026-03-15 | 398 天 |
| 自 2026-03-15 起 | 2027-03-15 | 200 天 |
| 自 2027-03-15 起 | 2029-03-15 | 100 天 |
| 自 2029-03-15 起 | — | 10 天 |
再看一眼最后一行。有效期是「缩短」到 47 天，而域名验证(DCV)复用则是「崩塌」到 10 天。这是复用期限第一次比证书有效期本身还短的区间。也就是说，47 天的证书每次续期时，大概率没法复用上一次的验证结果，续期实际上变成了「每次都要重新验证」。非域名/IP 的主体身份信息(比如 OV 证书里的组织信息)的复用期限，也会从 2026-03-15 起从 825 天降到 398 天。
投票文本自己说清楚了这份时间表要解决什么问题 — 证书是签发那一刻事实的快照，而随着时间推移，快照和现实之间的落差会越拉越大；同时，撤销(revocation)基础设施在互联网规模下，无论是扩展性、可靠性还是用户成本，都没能真正发挥作用，于是干脆缩短有效期本身，让保护变得「确定无疑」。有一处细节很有意思 — 投票文本自己把自动化的普及称为「附带的好处(ancillary benefit)」。顺序不是「为了推动自动化而缩短有效期」，而是「缩短有效期，自动化顺带跟上来」。
投票结果说明了什么 — 2019 年与 2025 年
这样的尝试并非首次。2019 年的 SC22 投票提议把最长有效期缩短到一年，但在 CA 一侧的投票中以赞成 11 票、反对 20 票(弃权 2 票)被否决，赞成率只有 35%。相比之下，浏览器一侧(Apple、Cisco、Google、Microsoft、Mozilla、Opera、360)7 票全部赞成。结果是，尽管投票被否决，根据 BR 的修订历史，398 天的上限还是从 2020-09-01 起生效了 — 相当于根证书程序(root program)在论坛投票之外自行定下了方向。
2025 年的 SC-081v3 情形则完全不同。这份提案由 Apple 的 Clint Wilson 发起，Sectigo、Google Chrome、Mozilla 附议，在 2025-04-11 截止的投票中，CA 一侧 30 票里赞成 25 票、反对 0 票、弃权 5 票(Entrust、IdenTrust、Japan Registry Services、SECOM Trust Systems、TWCA)通过。浏览器一侧 4 票全部赞成。2019 年投过反对票的 GoDaddy、GlobalSign、D-TRUST、Izenpe、SwissSign 这次都转为赞成，而 2019 年的反对阵营里，SECOM 和 TWCA 这次退到了弃权。零反对票这个结果，一方面说明业界已经接受了这个方向，但更诚实地说，恐怕也是 2020 年那次「反正根证书程序说了算」的经验教训被吸收了的结果。
Let's Encrypt 的实际过渡日期 — 90 → 64 → 45
BR 的时间表只是上限，运营者实际感受到的是自己所用 CA 的时间表。2025 年 12 月，Let's Encrypt 公布了从 90 天缩短到 45 天的计划，并敲定了具体日期。过渡是按ACME 配置文件(profile)逐个推进的。
- 2026-05-13 —
tlsserver配置文件切换为 45 天证书。这是一个需要主动选用(opt-in)的配置文件，面向早期尝鲜者和测试场景。这一步已经落地，目前的配置文件文档也已更新为 45 天。 - 2027-02-10 — 默认的
classic配置文件切换为 64 天证书，外加 10 天的授权(authorization)复用。凡是没有另外选择配置文件的用户，都属于这一档。 - 2028-02-16 —
classic切换为 45 天证书，外加 7 小时的授权复用。
每一次变更，都会先在预发布(staging)环境上线大约一个月，再上生产。有两点值得注意 — 45 比 47 小(留出了前面提到的 86,400 秒规则和「不要卡上限发证」这条 BR 条款的余量)，而 2028-02-16 这个日期比 BR 强制要求 47 天的 2029-03-15 早了大约十三个月。Let's Encrypt 比 BR 的截止日期提前了整整一年在推进。
按文档口径(截至 2026-07-14 更新版)对比一下当前生产目录(directory)公布的三种配置文件，如下表所示。
| 属性 | classic | tlsserver | shortlived |
|---|---|---|---|
| 证书有效期 | 90 天 | 45 天 | 160 小时(略超 6 天) |
| 授权复用 | 30 天 | 7 小时 | 7 小时 |
| 挑战(challenge)完成期限 | 7 天 | 1 小时 | 1 小时 |
| 订单有效期 | 7 天 | 8 小时 | 8 小时 |
| CN / KE-KU / SKID | 包含 | 移除 | 移除 |
| 最大名称数 | 100 | 25 | 25 |
| 标识符类型 | DNS | DNS | DNS、IP |
tlsserver 的授权复用之所以定为 7 小时，是有原因的 — BR 要求签发前 8 小时以内要重新核对 CAA 记录，把复用期限设为 7 小时，就可以彻底不用重新核对了。至于续期量会不会暴涨的担心，Let's Encrypt 专门给出了答复 — 从「90 天证书在第 60 天续期」变成「45 天证书在第 30 天续期」，续期请求量确实会翻倍，但续期是不计入速率限制的，所以不会影响新域名签发的上限(每个账户每天 300 个)。
6 天证书与 IP 证书 — 已经正式可用
比时间表的终点(47 天)走得更远的选项，其实已经存在了。Let's Encrypt 的 shortlived 配置文件自 2026 年 1 月 15 日起正式可用。有效期 160 小时 — 落在 BR 从 2026-03-15 起认定的「短期订户证书(Short-lived Subscriber Certificate)」7 天(604,800 秒)上限之内。一旦被归为短期证书，BR 规定的撤销支持义务就从强制变成可选。就算密钥泄露，6 天后自然到期，也就不用依赖不可靠的撤销基础设施，而是靠有效期本身来提供保护。不过目前这个配置文件签发的证书里，CRL URL 仍然保留着 — 要不要去掉，讨论正在 boulder#7673 中进行。
2025 年 7 月首次签发、随后与 shortlived 一起正式可用的 IP 地址证书，必须使用 shortlived——这是 Let's Encrypt 定下的政策，理由是 IP 的所有权比域名更换得更频繁。certbot 一侧的支持在今年 3 月理清了 — 配置文件选择标志 --preferred-profile 从 certbot 4.0 开始支持，--ip-address 标志从 5.3 开始，webroot 模式下的 IP 支持则从 5.4 开始。不过 nginx、apache 的安装插件目前还不支持 IP 证书，需要通过部署钩子(deploy hook)自己接上。
值得原样转述的是，Let's Encrypt 自己也说短期配置文件「不是为所有人准备的」，并且明确表示没有把它设为默认值的打算。一张 160 小时的证书，只要续期流水线停摆大约四天，就会直接导致过期。在完全信任自动化之前，不要轻易选它。
不要把续期时机写死 — ACME ARI(RFC 9773)
「到期前 30 天续期」这类硬编码，是 90 天时代留下的遗物。与其在有效期从 90 到 64 到 45 天不断变化时反复调整这个阈值，不如用一个已经存在的标准，让 CA 直接告诉你什么时候该续期 — 这就是 2025 年 6 月发布的 RFC 9773，ACME Renewal Information(ARI)。从 2021 年 9 月的第一份草案到最终标准化，走了四年，而 Let's Encrypt 早在草案阶段的 2021 年底就已经在服务端(Boulder)支持它了。我也核实过，目前生产目录上 renewalInfo 端点确实已经上线。
原理很简单。客户端用证书的 AKI 和序列号拼出一个标识符发起查询，服务端返回一个建议的续期窗口。
GET {renewalInfo}/base64url(AKI keyIdentifier).base64url(Serial)
HTTP/1.1 200 OK
Retry-After: 21600
{
"suggestedWindow": {
"start": "2025-01-02T04:00:00Z",
"end": "2025-01-03T04:00:00Z"
},
"explanationURL": "https://acme.example.com/docs/ari"
}
客户端在这个窗口内随机挑一个时间点续期，并按 Retry-After 给出的间隔重新查询，看窗口是否发生了变化。续期订单可以用 replaces 字段指明要替换的上一张证书，CA 可以据此按自己的策略来做续期识别和速率限制。RFC 甚至规定了对已过期的证书不应(MUST NOT)再继续查询。
这个协议真正的价值不在平时，而在出事故的时候。当 CA 不得不进行大规模撤销时 — Let's Encrypt 曾在 2022 年 1 月因 TLS-ALPN-01 验证的一个漏洞撤销了约 200 万张证书 — CA 可以把续期窗口提前来响应，而正在关注 ARI 的客户端就能在撤销真正执行之前完成替换。在 24 小时、5 天这样的撤销期限内，靠人工介入的流程根本来不及覆盖大多数站点。Shopify 的案例堪称教科书 — 他们原本用「到期前 30 天 + 0 到 72 小时抖动(jitter)」的方式管理数百万个域名，后来直接向 Ruby 的 acme-client gem 贡献了 ARI 支持，把续期时机的决定权交给了 CA(效果的描述来自 Shopify 自己的说法，没有公开具体的量化数字)。
各客户端的支持现状如下，全部来自官方变更日志和文档的确认。
- certbot — 从 4.1.0(2025-06-10)起，
certbot renew会自动检查 ARI。在 Let's Encrypt 上，大致会在有效期三分之二处触发续期；从 5.0.0 起，Retry-After 会在多次运行之间被保留。 - lego — 除非命令行显式关闭，否则会检查 ARI，甚至已经实现了
replaces字段。 - Caddy/CertMagic — README 明确写明完整支持 RFC 9773。
- cert-manager — 最晚加入的一个。v1.21.0(2026-07-08) 在
ACMEUseARI功能开关(feature gate)背后加入了 ARI 支持。这是一个 2023 年 5 月就提出的需求 issue，隔了三年才有动静，而且目前还不是默认开启。如果你在 Kubernetes 上运行证书 — 也就是cert-manager 实战篇里讲的那一整套技术栈 — 就意味着升级版本和开启这个功能开关这两件事，都得单独处理。
对于没有 ARI 的客户端，Let's Encrypt 推荐的退路是坚持「在有效期三分之二处续期」。对 45 天证书来说，就是第 30 天。在 45 天时代，固定 60 天周期这种配置，本身就是一场等着发生的故障。
还没到来的部分 — DNS-PERSIST-01 的现状
有效期缩短这整套拼图的最后一块，是验证自动化。复用期限一旦崩塌，就得更频繁地做验证，而现在的 DNS-01 每次续期都得把新令牌写成 TXT 记录，这意味着 DNS API 凭证会在发证流水线的各个环节里不断流转。这就是 DNS-PERSIST-01 想解决的问题 — 一条指明 CA 和 ACME 账户的常设授权记录，一旦部署好，就不用每次续期都改动。
_validation-persist.example.com. IN TXT (
"letsencrypt.org;"
" accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"
)
加上 policy=wildcard 就能覆盖通配符和子域名，如果对常设授权不放心，也可以用 persistUntil 设置一个到期时间。制度层面的准备工作已经完成 — CA/B Forum 的投票 SC-088v3 在 2025 年 10 月全票通过，已经写入现行 BR 的 3.2.2.4.22 节("DNS TXT Record with Persistent Value")，同时收录了用于 IP 地址的 _ip-validation-persist 变体。
但实物还没出现。2 月公告设定的目标是「预发布环境在第一季度末上线，生产环境在第二季度上线」，可截至目前的真实状态是这样 — 预发布环境上有一份草案实现(4 月底 draft-01 更新后，accounturi 已成为挑战对象的必填字段)，生产环境尚未开放。Let's Encrypt 的一名工程师在 6 月 25 日于社区论坛给出的回复，准确概括了目前的处境 — 在 草案的 issue #64(要不要在记录里包含客户端计算出的信息)解决之前，他们不会上线部署。5 月的时候还有一条回复提到，「如果 IETF 那边的共识拖延，可能要推迟到第三季度」。官方的挑战类型文档里也还没收录它。简而言之，现在不应该把架构建立在 DNS-PERSIST-01 之上，能做的只是在预发布环境里试验一下。
公告本身也如实指出了设计上的权衡 — 把 DNS 写入凭证从流水线里挪走的代价，是常设授权被绑定在了 ACME 账户上，账户密钥因此变成了新的头号敏感信息(secret)。如果没有一套完善的账户密钥保管和轮换机制就直接用它，等于只是把风险挪了个地方。
那么，该准备些什么
把这份时间表翻译成运维语言，大致是这样。
- 先从盘点开始。要找出所有靠手动续期的证书 — 一年一次的日历提醒、按季度提工单、通过设备控制台上传文件 — 这是第一件要做的事。在 200 天时代，一年两次的手工操作还能撑住；但 100 天就得一年四次，47 天就大概是每个月一次了。手工操作的问题不在于次数本身，而在于次数越多，单次出错遗漏的概率就越会叠加放大。
- 客户端版本与 ARI。如果你用的是低于 4.1 的 certbot、没有 ARI 的自研脚本，或是固定周期的 cron 任务，现在就该升级。把续期时机的判断交给 CA，是应对这整份时间表最便宜的一份保险。
- 监控要盯的是「即将过期」，而不是「续期是否成功」。续期流水线悄无声息地挂掉，比大声报错失败更危险，而有效期越短，「悄无声息地挂着还能撑住」的时间窗口也就越短。对 45 天证书来说，两周的假期档期故障，就直接等于一次过期事故。
- 让验证环节也自动化。从 2027-02-10 起，Let's Encrypt 默认配置文件的授权复用会降到 10 天，2028 年降到 7 小时。「续期自动、验证(尤其是 DNS-01 的 TXT 记录更新)半自动」这种组合，会在这里出问题。在 DNS-PERSIST-01 上生产之前，要么接受管理 DNS 凭证的负担，要么转向 HTTP-01/TLS-ALPN-01，这个决定必须提前做。
- 短期配置文件放到最后再考虑。能消除撤销顾虑的 6 天证书很诱人，但正确的顺序是先在 45 天档位上平稳度过几个季度，再考虑更进一步。
反过来，这份时间表不强制要求的部分，也说清楚。BR 的适用范围是「用于互联网可访问服务器认证」的公开信任证书。用私有 CA 运行的内部 PKI、封闭网络里的设备、mTLS 用的内部证书，都可以完全不受这份时间表约束，自行决定有效期。如果一个不一定需要公开信任的内部系统扛不住 47 天的周期，与其硬上自动化，转向私有 PKI 也是一个合理的答案 — 这个判断本身，正是无停机续期操作手册里讲过的运维原则的延伸。
结语
总结一下。日期已经确定 — 200 天(已生效)，2027-03-15 起 100 天，2029-03-15 起 47 天，同一天验证复用降到 10 天。Let's Encrypt 又在此基础上叠加了自己的时间表 — 2027-02-10 默认 64 天，2028-02-16 默认 45 天。工具这边也大多就位了 — ARI 已经成为正式 RFC，并进入了主流客户端；6 天证书也已经正式可用。唯一还没到来的，是 DNS-PERSIST-01 的生产部署，而即便是它，制度层面和预发布测试也都已经完成。
所以真正剩下的变量，既不是标准，也不是 CA，而是各自的运维。47 天时代的失败模式，不是「忘了续期」，而是「自动化悄悄地死掉了」。现在该做的，不是在日历上把续期提醒钉得更密，而是搭建一条不靠提醒也能自己跑起来的流水线，以及这条流水线一旦挂掉就会响起的警报。
参考资料
- Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods — CA/B Forum(投票结果及完整投票文本)
- TLS Baseline Requirements 原文 — 6.3.2 有效期时间表、4.2.1 复用时间表
- Ballot SC22: Reduce Certificate Lifetimes(v2) — 2019 年被否决的记录
- Decreasing Certificate Lifetimes to 45 Days — Let's Encrypt(90→64→45 过渡日期)
- Certificate Profiles — Let's Encrypt 文档(classic/tlsserver/shortlived 属性对照表)
- 6-day and IP Address Certificates are Generally Available — Let's Encrypt
- Shorter Certificate Lifetimes and Rate Limits — Let's Encrypt
- Six-Day and IP Address Certificates Available in Certbot — Let's Encrypt
- RFC 9773 — ACME Renewal Information(ARI) Extension
- ACME Renewal Information(ARI) Published as RFC 9773 — Let's Encrypt
- Simplifying Certificate Renewals for Millions of Domains with ARI — Shopify 的案例
- DNS-PERSIST-01: A New Model for DNS-based Challenge Validation — Let's Encrypt
- dns-persist-01 部署状态帖 — Let's Encrypt 社区(2026-06-25 官方回复)
- cert-manager v1.21.0 发布说明 — ACMEUseARI 功能开关
- 为什么 PQ 证书还没来 — ML-DSA 签名大小与 Merkle Tree Certificates(相关文章)
현재 단락 (1/93)
2026 年 3 月 15 日，公开信任(publicly-trusted)TLS 证书的最长有效期从 398 天降到了 200 天。写这篇文章的时候，这已经是四个月前的事了。如果你的团队一直靠一年一...