时间紧迫：SSL证书有效期要缩短了

Let's Encrypt最近放了个大招，咱们搞开发、做运维的朋友都得留意一下。从2027年2月10号开始，他们签发的证书默认有效期从原来的90天直接砍到64天。

不过说真的，这事儿早就有苗头了。Let's Encrypt早就放出风声，而且你要是关注安全圈动态的话，缩短证书有效期这事早就是明摆着的趋势。道理很简单——证书存活时间越短，被破解的密钥或者错误签发的证书能造成的损害就越小。

2027年2月10号到底会变什么？

咱们把时间线捋一捋：

• 2027年2月10日：所有新签发和续期的证书都是64天有效期
• 2027年5月11日：最后一批90天证书（赶在截止前签发的）终于失效
• 2028年：预计还要再砍一刀，变成45天
• 2029年：授权复用时间大幅压缩到只有7小时

好消息是啥？Let's Encrypt会在2026年10月14号先在预发布环境里把这个改动放出来，给大家留出测试时间。强烈建议大家好好利用这个窗口期。

你的证书管理跟得上吗？

这部分挺关键的，看看自己需要做什么准备。

如果你用的是支持ARI的ACME客户端

要是你的自动化续期工具用的是支持ACME Renewal Info（ARI）的客户端，那情况可能还好。ARI让Let's Encrypt能直接跟你的客户端"对话"，告诉它什么时候续期最合适。本质上就是更聪明、更灵活的方式，不用死板地卡着固定时间表。

但这里要敲黑板了——别觉得自己肯定没问题。一定要确认一下你用的客户端文档里明确写了ARI功能已经实现并且正常工作。想当然是大忌，很多故障就是这么来的。

如果你硬编码了续期日期

很多人都在这儿栽过跟头。什么叫硬编码？比如说你的续期逻辑写成"到期前30天续"或者"每90天续一次"，这种写法就得改了。

Let's Encrypt的建议是按照证书有效期的三分之二来触发续期。64天的证书，大概就是42到43天。不过有个小技巧：如果你现在就改成80天左右触发90天证书的续期，那切换的时候就不用手忙脚乱了。

赶紧用grep搜一下你的定时任务、脚本和运维手册里有没有83、80、60、30这些数字。发现了就说明有硬编码逻辑，得改。

授权复用：这个改动很容易被忽略

公告里还有个变化值得单独说说：授权复用期限要从30天缩短到10天。

对大多数用户来说，这个不需要特别处理。授权复用是个优化手段，让ACME客户端在近期已经验证过域名控制权的情况下，不用再重复验证。除非你的基础设施专门依赖这个机制，否则基本不用管。

不过Let's Encrypt做这个改动是为了取消"CAA重新检查"这个环节——以前验证数据超过7小时旧就得重新验证。2029年开始，最大验证复用期会直接缩到7小时，这次调整算是提前铺路。

是时候升级你的证书管理了

说点真心话：这次变化其实是个好事。不是因为缩短有效期本身方便（说实话确实不方便），而是因为它逼着咱们不能再把证书管理当成"配一次就不管了"的事儿了。

要是你现在还在每隔89天SSH登录服务器手动续证书，那就是在踩雷。证书过期从来不挑时候——周五下午、节假日、系统故障的半夜——自动化把这些情况全解决了。

趁这个机会，建议加上这些：

• 续期失败的告警：证书过期之前就收到通知，而不是过期之后才发现
• 自动化部署：把证书续期直接对接上服务重载流程
• 健康检查：监控你整个基础设施里所有证书的到期时间

总结一下

Let's Encrypt在速率限制、ACME接口、证书链这些方面都没动，就是单纯调整了有效期。这个改动符合整个行业向更短证书有效期靠拢的趋势，安全上是有道理的。

如果你已经在用自动化续期工作流，过渡应该会比较顺利。剩下的那些朋友，就当这是督促你赶紧把证书自动化做起来的信号吧。

预发布环境2026年10月开放测试，这就是你的练兵场，好好用。

关于SSL、证书自动化或者怎么为这些变化做准备有疑问？ 随时可以联系我们，我们可以帮你检查现有配置，确保你能顺利过渡。

注意安全，你用户和值班同事都会感激你的。