Let’s Encrypt 45 天证书：时间表及准备方法

介绍#

Let's Encrypt 正在将其证书有效期从 90 天缩短到 45 天。这一变化将于 2026 年至 2028 年间分阶段实施，而且这并不只是 Let's Encrypt 的决定：CA/Browser Forum 已经投票决定，到 2029 年 3 月将所有公开信任的 TLS 证书上限设为 47 天。对于管理数百甚至数千个域名的团队来说，续期不再是周期性的琐事，而必须变成自动运行的事情。

如果你的团队仍然在手动处理 SSL 续期，你很快就会感受到压力。原本一年四次的续期周期将变成八次。原本可控的季度任务将变成持续性的运维负担。时间表已经启动，提前准备的基础设施团队将能平稳度过这一过渡；没有准备的团队将面临更高的故障风险和不断增加的运维开销。

本指南涵盖具体日期、续期将发生哪些变化、ACME 自动化与手动证书管理的对比，以及针对重定向域名和停放域名的检查清单——这些证书最容易被遗忘。

公告：Let's Encrypt 将证书有效期从 90 天缩短到 45 天#

2025 年 12 月，Let's Encrypt 宣布将分阶段把证书有效期从 90 天缩短到 45 天，并缩短域名验证（授权）的可复用时长。这些变更适用于新签发的证书，因此你会在每个日期之后的下一次续期时看到更短的有效期。

Let's Encrypt 自推出以来一直签发 90 天证书，那时大多数商业证书的有效期是一年或更长。短有效期的初衷是推动所有人走向自动化。缩短到 45 天延续了这一方向，并与下方的行业整体时间表保持一致。

实际影响很直接：每个由 Let's Encrypt 保护的域名都需要将证书续期频率提高一倍。对于已经自动化续期流程的组织来说，这一过渡可能几乎无感。对于依赖手动流程或半自动化工作流的团队来说，运维影响将非常显著。

原因：安全最佳实践——缩小被攻破窗口#

更短的证书有效期本质上是一种安全改进。每个 TLS 证书都代表一个潜在的攻击面。如果证书的私钥被泄露，攻击者就可以冒充合法域名，直到证书过期或被吊销。证书有效期越长，这个被攻破的窗口就会保持开启越久。

四十五天证书将这一窗口期缩短了一半，相比当前 90 天的标准。如果某个密钥在第一天就被泄露，最大暴露时间将是 45 天，而不是 90 天。实际上，暴露时间通常会更短，但这个上限很重要——尤其是对于那些可能无法立即发现泄露的组织。

关于撤销也有一个论点。通过 CRL 和 OCSP 进行的证书撤销在历史上并不可靠。浏览器并不总是会一致地检查撤销状态，而且被撤销的证书有时仍会继续被信任。更短的有效期降低了对撤销基础设施的依赖。如果一张证书只存活 45 天，那么撤销它就没那么关键了——反正很快就会过期。

安全社区长期以来一直倡导缩短证书有效期。Let's Encrypt 的这一举措，将安全研究人员多年来一直建议的做法真正落到了实处。

不仅仅是 Let's Encrypt：CA/Browser Forum 的 47 天规则#

在 2025 年，CA/Browser Forum——制定公共 TLS 证书规则的证书颁发机构和浏览器厂商组织——通过了提案 SC-081v3。该提案分三步将所有公开信任证书的最长有效期下调，适用于包括 DigiCert、Sectigo 和 GlobalSign 在内的所有 CA，并缩短了域名验证结果可重复使用的时长：

因此，如果你今天购买一年期商业证书，它们的有效期上限已经是 200 天，并且接下来还会沿着同样的路径继续缩短到 47 天。短有效期如今已成为整个网络的规则，而不再只是某一家免费 CA 的特殊做法。

Let's Encrypt 时间线：重要日期#

每项更改都会在正式环境上线前大约一个月先进入 Let's Encrypt 测试环境，因此你可以先在其中测试你的配置。

7 小时的授权重用是最容易让人踩坑的变化。如今，某个域名一旦验证过一次，之后几周内都可以直接重新签发，而无需再次验证。从 2028 年起，几乎每次续期都需要重新验证，因此 DNS 记录或 HTTP 挑战在续期时仍必须可用，而不只是你最初设置该域名的那一天可用。

Let’s Encrypt 还提供一个短期配置文件，为希望更进一步的团队提供 6 天期证书。

实际的截止时间取决于你的续期计划。Let’s Encrypt 表示，固定的 60 天续期间隔已不再足够。如果你的客户端支持 ACME Renewal Information（ARI），请使用它，这样 CA 就能告诉你何时续期；如果不支持，则应在证书生命周期的大约三分之二时进行续期。

45 天到底意味着什么：每年 8 个续期周期，而目前是 4 个#

数学很简单，但运营影响并不简单。从 90 天证书转向 45 天证书意味着：

续期频率翻倍。 每个域名不再是每年 4 个续期周期，而是 8 个。对于管理 100 个域名的团队来说，这意味着每年要处理 800 次续期事件，而不是 400 次。对于管理成千上万个域名的团队，如果没有完全自动化，这个数字会变得难以应付。

续期窗口缩短。使用 90 天证书时，在到期前 30 天续期仍有充足缓冲。使用 45 天证书时，在生命周期的三分之二时续期，只剩大约 15 天来发现并修复故障。

容错空间降低。 使用 90 天证书时，续期失败后你还有数周时间在过期前排查并解决问题。使用 45 天证书时，你只有几天时间。每一次续期失败都更加紧迫，监控也需要更灵敏。

速率限制会成为一个问题。 Let’s Encrypt 对证书签发实施速率限制。将续期频率翻倍意味着你会消耗双倍的速率限制配额。对于在 90 天证书上接近限制的团队来说，到了 45 天证书可能会触及限制，并需要调整签发模式。

结论： 在 90 天时勉强可用的手动或半自动续期流程，在 45 天时将会失效。完全自动化已不再是可选项。

这对谁影响最大：管理 100 个以上域名且使用手动 SSL 流程的团队#

45天证书时代并不会对所有人产生同样的影响。以下是受影响最严重的群体：

域名投资者和组合管理者。 管理数百或数千个停放、重定向或变现域名的团队面临最大的运营负担。每个域名都需要自己的证书。即使在90天周期下，手动续期在如此规模下也已经很痛苦。到了45天，这就不可行了。

管理客户域名的代理机构。 数字代理机构通常为数十或数百个客户域名管理 SSL。每个客户可能使用不同的基础设施、不同的续期流程，以及不同程度的自动化。45天的时间表会放大续期工作流中的每一个不一致之处。

拥有多个店面的电商平台。 多品牌电商业务会为每个品牌、每个地区和每个活动运行独立域名。证书数量会迅速增加，续期负担也会随之加重。

使用自定义域名的 SaaS 平台。 允许客户接入自有域名的 SaaS 产品通常会在入驻流程中处理 SSL 配置。对于45天证书而言，续期基础设施必须足够可靠——客户域名一旦续期失败，他们的网站就会显示安全警告。

对于完全通过 ACME 自动化续期的团队来说，可能根本不会感觉到变化。证书生命周期被自动续期的基础设施所抽象掉了。分界线在于自动化——如果你的续期流程需要人工查看仪表板或运行脚本，那么你就站在了不利的一边。

企业就绪差距#

很多团队多年前就已经自动化了证书管理，之后再也没回头检查过。问题通常出现在同样的地方：

证书记录在电子表格里而不是被监控，续期脚本需要有人手动触发，过期提醒发到没人看的收件箱，以及那些只是做重定向的域名，因此没人会想到它们也有证书。

就绪差距在那些很早采用 Let's Encrypt、但从未完全自动化其续期流水线的组织中最为明显。他们五年前在几台服务器上安装了 Certbot，添加了一个 cron 任务，然后就再也没有重新审视过这套配置。这些 cron 任务可能每60天才运行一次——对于45天证书来说，这样的频率远远不够。

现在就审计吧，趁你还有 90 天证书作为安全缓冲：列出每一份证书，确认它们都能自动续期，并测试续期失败时会发生什么。

ACME 与手动证书管理#

重定向和停放域名检查清单#

仅做重定向的域名很容易被忘记，但输入 https:// 的访客在重定向发生之前仍需要有效的证书。在 2027 年和 2028 年日期之前：

1. 列出每个会重定向的域名，包括旧品牌、拼写错误域名和活动域名，以及根域和 www。
2. 为每个域名注明是谁签发其证书以及如何续订。"注册商的转发"通常意味着根本没有 HTTPS。
3. 检查每个 ACME 客户端是否支持 ARI，或者是否在证书有效期的三分之二时续订，而不是按固定的 60 天 cron 任务续订。
4. 确保在续期时验证仍然有效：DNS 仍然指向 HTTP 验证被响应的位置，或者 DNS 验证凭据仍然可用。
5. 设置过期监控，向共享频道发出告警，而不是发送到某一个人的收件箱。
6. 在每次生产环境变更前，都先针对 Let's Encrypt 测试环境进行测试。

或者，干脆将重定向域名从你的清单中移除，把它们迁移到一个重定向平台上，该平台会为其托管的每个域名签发并续期 HTTPS。

结论#

45 天证书时代即将到来，这不仅仅是 Let's Encrypt 的政策变化——它更是整个行业在安全最佳实践推动下，朝着更短证书有效期迈进的转变。对于企业团队来说，哪些会受到影响、哪些不会受到影响之间的分界线很简单：自动化。

如果你的 SSL 续期流水线已经通过 ACME 完全自动化——如果证书能够在无人干预的情况下自动续期、安装并验证——那么除了更新一个配置参数之外，你可能根本不会注意到这项变化。如果你的续期流程涉及任何手动步骤、电子表格或由人工触发的脚本，45 天的时间线将暴露出你基础设施中的每一个缺口。

实际步骤很直接：盘点你的证书库存，验证自动化覆盖范围，测试续期失败场景，并确保监控能在用户看到浏览器警告之前捕获过期情况。现在就采取这些措施的团队——在时间窗口缩短之前——将平稳度过这次转变。

在运行重定向域名吗？查看如何在不出现证书错误的情况下通过 HTTPS 重定向域名。