SSL证书有效期缩短：2026年站长需要调整哪些续期流程
网页使用的“SSL证书”，如今实际主要指TLS服务器证书。对站长来说，有效期缩短意味着需要更可靠的续期、部署和监控流程。证书采购订单的服务年限，并不等于每一张证书的有效期；购买多年服务，也可能需要在服务期内多次重新签发。
本文按2026年9月4日查阅的官方资料整理，适用于公开信任的TLS服务器证书。内部私有CA、代码签名等证书不能直接套用下面的时间表。
行业上限已经进入200天阶段
根据CA/Browser Forum基线要求第6.3.2节，按签发时间划分，公开信任TLS订阅者证书的最长有效期如下：
| 签发时间 | 最长有效期 |
|---|---|
| 2026年3月15日之前 | 398天 |
| 2026年3月15日至2027年3月14日 | 200天 |
| 2027年3月15日至2029年3月14日 | 100天 |
| 2029年3月15日起 | 47天 |
这是行业允许的上限，并不表示证书机构必须签发到这个天数，也不意味着所有已签发证书在切换日统一失效。实际到期时间仍应查看证书的Not After字段。证书机构还可能采用更短期限或更早推进自己的调整。
Let's Encrypt有独立的迁移节奏
Let's Encrypt公布的计划包括：2026年5月13日，其可选tlsserver配置开始签发45天证书；2027年2月10日，默认classic配置将调整为64天；2028年2月16日进一步调整为45天。时间表针对调整后的新签发证书，普通用户会在相应续期时遇到期限变化。
因此，“2026年所有证书都只剩47天”是不准确的。排查和规划时应先确定当前使用哪家CA、哪个证书配置和哪个续期客户端，再阅读该服务的实施通知。不要仅凭浏览器显示的签发机构名称推断自动化链路已经就绪。
先做证书清单，再谈自动化
把业务域名、证书终止位置、申请方式、到期时间、续期任务和负责人记录在一起。一个域名可能在CDN边缘、负载均衡和源站分别使用证书；更新源站文件，不代表边缘已经更新。通配证书与普通域名证书也可能采用不同验证方式。
清单中还应包含容易遗漏的服务：管理面板、接口子域名、邮件相关HTTPS入口及监控页面。优先找出人工下载并上传证书、依靠个人日历提醒和无人负责的入口。这里的整理方式是运维建议，可根据团队规模简化成一张表。
续期成功不等于用户已经拿到新证书
自动化需要覆盖申请、验证、安装、服务加载和外部检查。客户端显示续期成功后，还应从服务外部确认域名实际提供的新证书、证书链与到期日期。多节点部署要逐个核对，避免部分节点继续提供旧版本。
对于Nginx等服务，加载新配置前先做语法检查，再按部署方式重新加载。若证书由平台托管，确认平台负责的具体环节、失败通知位置及故障处理方式。不要假定购买了服务器就自动包含全部证书维护。
用演练发现续期依赖
在支持的测试环境或续期演练模式下，检查HTTP验证路径是否可访问、DNS验证权限是否足够、任务账户是否能读写必要文件，以及代理或防火墙调整是否破坏验证链路。DNS凭据只授予所需范围，并放入受控的密钥管理位置。
也要测试续期失败时告警是否真正到达负责人员。有效期越短，固定“到期前30天提醒”的经验越需要重新评估；根据证书实际期限和修复所需时间，设计多级提醒与重试间隔。不要靠频繁强制签发生产证书来验证流程，以免触发CA限制。
现在可以完成的三件事
第一，导出在用证书清单，找出人工续期和没有负责人监控的项目。第二，在低风险域名上验证完整自动续期与部署，再逐步推广。第三，把证书到期与外部HTTPS可用性纳入常规巡检，并为凭据到期、DNS变化和服务迁移建立交接记录。
证书期限变短带来的工作量，主要取决于流程是否依赖人工。提前建立可观测、可恢复的维护链路，能让下一轮期限调整更容易处理。