每个人都可以，
拥有SSL证书

Let's Encrypt把证书有效期从90天压到45天，这事不再停留在讨论阶段。

2027年2月10日先降到64天，2028年2月16日直接到45天。授权复用期更狠，从10天缩短到7小时。还在靠人工申请、手动更新Nginx或Apache证书的团队，基本可以提前准备每周一次的证书轮换节奏了。

很多人没意识到授权复用期的杀伤力。ACME协议里，你验证一次域名所有权，在复用期内可以反复申请证书不用重新验证。以前这个窗口有10天，证书过期前一两天发现没续上，重新申请时大概率还能蹭到旧的授权。现在缩到7小时，意味着一旦错过续期窗口，必须重新做DNS TXT记录或者HTTP文件验证。实际运维中常见的报错就长这样：

urn:ietf:params:acme:error:unauthorized
The client lacks sufficient authorization

这个错在授权过期后申请证书时频繁出现。你上一次验证是昨天下午，今天上午申请，授权已经失效。

没有自动化重新验证流程的话，只能手动登DNS控制台改记录。

另一个容易被忽略的变化是OCSP URL被移除，改用CRL分发点。以前浏览器检查证书是否被吊销，走的是在线查询，类似打客服电话问“这张证书还有效吗”。现在改成下载吊销列表自己比对。CRL文件比OCSP响应大得多，对终端缓存和网络策略都有影响。企业内网如果之前把OCSP域名加了白名单，现在需要重新梳理CRL分发点的访问规则。

45天有效期加上7小时授权复用期，对手工运维的冲击是全方位的。

通配符证书、多域名证书、纯IP证书，这些场景下手工流程更脆弱。一个运维手里管着几十张证书，每张证书的到期时间、授权状态、部署位置都不一样。在90天时代，靠Excel表格加日历提醒还能勉强应付，到45天时代，漏一张就是生产事故。

Let's Encrypt自己也清楚这套变化会逼死手工流程，所以推了ACME Renewal Information，简称ARI。每个证书下发时带一个建议续期窗口，自动化客户端可以精确计算什么时候该发起续期。

但很多自建脚本还在用固定30天提前续期的逻辑，证书有效期缩短后，这种固定阈值策略会失效。比如有效期45天，你设定提前30天续期，意味着证书刚发15天就开始走续期流程，浪费配额且容易触发CA频率限制。

行业里已经在往基于ACME协议的自动化平台迁移。lcjmSSL这类平台把Let's Encrypt、Google Trust Services、ZeroSSL这些支持ACME的CA封装成统一接口，提供API做申请、验证、部署、续期。核心价值就一点：授权复用期、ARI窗口、CRL变更这些底层细节，平台替你消化掉。你只需要关心证书绑定到哪个服务，剩余动作由自动化流程完成。

多域名、泛域名、IP证书都走同一套逻辑，不需要为不同CA写不同脚本。

一个值得注意的细节是短周期证书。

Let's Encrypt现在通过ACME Profiles可以申请更短有效期的证书，用于测试或者临时环境。生产环境用45天证书已经够短了，测试环境完全可以申请7天甚至更短的证书。前提是自动化链路要足够顺滑，否则短周期证书会把人工成本放大好几倍。

证书有效期继续往下走是大概率事件。CA/B论坛的基线要求已经把45天当成目标，未来不排除进一步压缩到30天甚至更短。到那时候，任何依赖手工介入的证书管理动作都会成为单点故障。对于还在用cron跑certbot renew的团队，现在要做的不是祈祷Let's Encrypt改主意，而是把续期流程从“定期手动触发”改成“事件驱动自动执行”。lcjmSSL这种平台的意义不在于免费证书本身，而在于把证书生命周期从人的手里交还给系统。