Let's Encrypt 45天证书：企业团队需要知道的事项

简介#

SSL 证书领域即将迎来数年来最重大的变化。全球最大的证书颁发机构 Let's Encrypt 正在将证书有效期从 90 天调整为 45 天。对于管理数百或数千个域名的企业团队而言，这并非小幅调整——而是 SSL 证书管理必须如何运作的根本性转变。

如果你们团队仍在手动处理 SSL 续期，那么你们很快就会感受到压力。原本一年四次续期变成一年八次。原本可控的季度性任务变成了持续性的运维负担。时间表已经在推进中，提前准备的基础设施团队将能更顺利地完成过渡；不准备的团队将面临更高的停机风险和不断增加的运维成本。

本文将解析该公告、其背后的原因、过渡时间表会是什么样，以及企业团队应当如何准备。

公告：Let's Encrypt 将证书有效期从 90 天调整为 45 天#

Let's Encrypt 于 2026 年年中宣布其计划将最大证书有效期从 90 天降低至 45 天。该变更将影响过渡日期之后签发的所有新证书。现有证书将在到期前继续被认可，但续期将适用新的 45 天有效期。

这并非一项突然的决定。Let's Encrypt 自上线以来一直在逐步缩短证书有效期。他们最初从 90 天开始，当时大多数商业 CA 提供的是一年期证书。转向 45 天延续了行业整体朝向更短有效期证书的趋势。

实际影响很直接：所有由 Let's Encrypt 保障的域名都需要更频繁地续期——频率将提高一倍。对于已经自动化续期流程的组织而言，过渡可能会很顺畅。对于依赖手动流程或半自动化工作流的团队而言，运维影响将非常显著。

为什么会发生：安全最佳实践——限制被攻破的窗口期#

更短的证书有效期从根本上是一项安全改进。每个 TLS 证书都代表一种潜在的攻击途径。如果证书的私钥被泄露，攻击者可以在证书到期或被吊销之前冒充合法域名。证书有效期越长，被攻破的窗口期就越长。

45天证书会将这一窗口相比当前90天标准缩短一半。如果在第1天密钥遭到泄露，那么最大暴露时间为45天，而不是90天。实际情况中暴露通常更短，但上限很关键——尤其是可能无法立即发现泄露的组织。

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

安全社区长期以来一直呼吁缩短证书有效期。Let's Encrypt 的行动将安全研究人员多年来的建议落地。

谷歌在 CA/浏览器论坛提出的并行方案——这不仅仅是 Let's Encrypt#

Let's Encrypt 并非单独行动。谷歌正在通过 CA/浏览器论坛推进一项并行提案，将行业范围内的证书最大有效期降低到45天。这将影响所有证书颁发机构，而不仅仅是 Let's Encrypt——包括 DigiCert、Sectigo 和 GlobalSign 等商业CA。

CA/B 论坛的提案仍在讨论中，但谷歌的参与表明，45天有效期很可能会成为行业标准，而不仅仅是 Let's Encrypt 的政策。当最大的浏览器厂商与最大的证书颁发机构在安全策略上达成一致时，采用通常会随之发生。

对企业团队而言，这意味着45天证书时代并不是 Let's Encrypt 特有的担忧。如果你今天使用的是有效期为一年的商业证书，你也应当预期这些有效期会同步缩短。整个 SSL 证书生态正在向短生命周期证书迈进，而这一转变已经在进行中。

时间线：变更何时发生，以及过渡期会是什么样子#

Let's Encrypt 已经表明将分阶段推出。具体日期仍在最终确定中，但预计时间线遵循类似于他们此前缩短有效期的模式：

**公告阶段（当前）：** 公开沟通、文档更新以及工具准备。像 Certbot 和 ACME 库这样的客户端软件将收到更新，以支持新的有效期。

**分阶段推行：** 45 天的有效期首先适用于一部分新的证书签发，允许 Let's Encrypt 监测潜在问题，并收集有关续期模式的数据。

**全面强制：** Let's Encrypt 签发的所有新证书都将采用 45 天的最长有效期。现有的 90 天证书将继续有效，直到其自然到期。

对于企业团队而言，实际截止时间是你当前自动化在过渡后进入续期周期的时点。如果你今天的证书每 60 天续期一次，那么在政策变更后，你大约还有一个续期周期的时间，然后才会开始签发 45 天证书。

45 天到底意味着什么：每年 8 次续期周期，而不是当前的 4 次#

计算很简单，但运行影响并不轻微。从 90 天证书迁移到 45 天证书意味着：

**续期频率翻倍。** 每个域原本每年 4 次续期周期，现在变为 8 次。对于管理 100 个域的团队而言，每年将从 400 次增加到 800 次续期事件。对于管理数千个域的团队，如果没有完整自动化，这些数字将难以承受。

**续期窗口缩短。** 对于 90 天证书，大多数自动续期系统会在到期前 30 天开始尝试续期——从而留出舒适的 30 天缓冲期。对于 45 天证书，同样提前 30 天的时间只会留下 15 天的缓冲期。续期逻辑需要更积极，并且更可靠。

**容错能力下降。** 对于 90 天证书，续期失败会给你数周时间去排查并在到期前解决问题。对于 45 天证书，你只有几天时间。每一次续期失败都更紧迫，而你的监控需要更快速响应。

**速率限制将成为关注点。** Let's Encrypt 会对证书签发实施速率限制。续期频率翻倍意味着你将消耗两倍的速率限制配额。使用 90 天证书时已经接近限额的团队，可能在 45 天证书时触及限额，并需要调整其签发模式。

结论是：在 90 天时勉强可用的手动或半自动续期流程，在 45 天时将无法工作。全自动化不再是可选项。

最受影响的人群：使用手动 SSL 流程管理 100+ 个域名的团队#

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

**域名投资者和投资组合管理者。** 管理数百或数千个已停放、已重定向或已变现域名的团队承担的运营负担最大。每个域名都需要各自的证书。在 90 天时手动续期已经很痛苦；到了 45 天，就不现实了。

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

**拥有多个店铺的电商平台。** 多品牌电商运营会为每个品牌、每个地区以及每个活动分别使用独立域名。证书数量会迅速倍增，而续期负担也随之成倍增加。

**带自定义域名的 SaaS 平台。** 允许客户自带域名的 SaaS 产品通常会在入驻/上线流程中完成 SSL 证书的签发与配置。采用 45 天证书后，续期基础设施必须做到“万无一失”——客户域名的续期失败意味着他们的网站会出现安全警告。

如果你的 ACME 续期已实现全自动，可能几乎感受不到变化。证书生命周期被基础设施自动续期机制“抽象”掉了。关键分界在于自动化——如果你的续期流程需要人工查看仪表盘或手动运行脚本，那么你就在错误的一侧。

企业就绪度差距#

行业调查描绘出令人担忧的图景。尽管 Let's Encrypt 已可用多年，且 ACME 自动化成熟度不断提升，仍有相当比例的组织通过手动或半自动流程来管理 SSL 续期。

常见差距包括：通过电子表格管理证书，而不是使用自动化监控；需要手动触发的续期脚本；发送到未被监控的邮箱的到期提醒；以及在没有集中续期协调的情况下，将通配符证书部署到整个基础设施中。

就绪差距在那些较早采用 Let's Encrypt、但从未真正把续期流程完全自动化的组织中最为明显。他们在五年前就在少数服务器上部署了 Certbot，添加了一个 cron 任务，却再也没有重新审视过这套配置。那些 cron 任务可能每 60 天运行一次——这对 45 天有效期的证书来说频率不够。

已经完成迁移的基础设施团队给出的建议也很一致：现在就审计你的续期流程。梳理基础设施中的每一张证书，确认续期已实现自动化并且被监控，同时测试你的故障恢复流程。45 天证书时代将暴露续期流程中的每一个漏洞。

结论#

45 天有效期证书时代正在到来，而且这不只是 Let's Encrypt 的政策变更——这是整个行业向更短证书生命周期的转变，源于安全最佳实践。对企业团队而言，真正的分界线很简单：那些感受到影响的人和那些没有感受到影响的人，差别在于自动化。

如果你的 SSL 续期流程通过 ACME 已实现全自动——证书续期、安装并完成校验都无需人工介入——那么你可能根本不会注意到这次变化，除了更新一个配置参数之外。如果你的续期流程包含任何手动步骤、表格或由人触发的脚本，那么 45 天的时间表将把基础设施中的每一个漏洞都暴露出来。

实际步骤很直接：盘点你的证书清单，核实自动化覆盖范围，测试续期失败场景，并确保监控能够在用户看到浏览器警告之前就捕捉到到期情况。那些现在就这样做的团队——在时间表进一步缩短之前——将能够平稳完成过渡而不发生事故。

现在就审计你的 SSL 续期流程。45 天时代即将到来——看看自动化 SSL 管理是如何运作的。