截至 2026 年 10 月 29 日,2026 年 3 月 15 日及之后签发的公开 TLS 证书(也就是常说的 SSL 证书)有效期最长 200 天。按照 CA/Browser Forum 定下的时间表,2027 年 3 月 15 日起上限降到 100 天,2029 年 3 月 15 日起再降到 47 天。
换句话说,2026 年 3 月 15 日及之后签发的公开 TLS 证书已经用不满一年,此前签发的证书不会因此被缩短,往后续期只会越来越频繁。证书哪天到期,可以在 Digily Link 的“SSL证书查询”里直接看到(Digily Link 是我们的产品)。续期计划则需要按新的时间表重新安排。
2026 年起 SSL 证书有效期的上限是多少
现在的上限是 200 天,依据是 CA/Browser Forum 的 Baseline Requirements(下称 BR)。截至 2026 年 10 月 29 日,BR 官方页面上的最新版本为 2.3.1,日期为 2026 年 10 月 4 日。其中第 1.2.2 节 Relevant Dates 写明,自 2026 年 3 月 15 日起,“Maximum validity period of Subscriber Certificates is 200 days”。Subscriber Certificates 指颁发给订户的终端证书,部署在网站服务器上的那张证书就属于这一类。
这条规则以签发时间为准。所以要判断一张证书适用哪个上限,得看它是哪天签发的,可以参考查询结果里的“发布于”。“发布于”是证书的生效时间,通常与签发时间相近,但不一定完全相同,临近切换日期时要格外留意。BR 规定的是最长期限,CA 可以签发比上限更短的证书,后文的 Let's Encrypt 就是例子。
BR 会持续修订,时间表以后也可能调整。如果你要据此规划未来几年的续期,动手前最好回官方页面核对一下当前版本号。
2026 至 2029 年证书有效期和验证复用期时间表
BR 的三个节点分别是 2026 年 3 月 15 日 200 天、2027 年 3 月 15 日 100 天、2029 年 3 月 15 日 47 天,域名验证数据的最长复用期也同步缩短为 200 天、100 天和 10 天。下表把 BR 的节点和 Let's Encrypt 自己的调整日期按时间顺序排在一起,方便对照。
| 生效日期 | 依据 | 证书最长有效期 | 验证数据复用期 |
|---|---|---|---|
| 2026 年 3 月 15 日 | CA/B Forum BR 第 1.2.2 节 | 200 天 | 域名和 IP 地址验证 200 天 |
| 2026 年 5 月 13 日 | Let's Encrypt tlsserver 配置(需自选) | 45 天 | 公告未单独列出 |
| 2027 年 2 月 10 日 | Let's Encrypt classic 配置(默认) | 64 天 | 授权复用 10 天 |
| 2027 年 3 月 15 日 | CA/B Forum BR 第 1.2.2 节 | 100 天 | 域名和 IP 地址验证 100 天 |
| 2028 年 2 月 16 日 | Let's Encrypt classic 配置(默认) | 45 天 | 授权复用 7 小时 |
| 2029 年 3 月 15 日 | CA/B Forum BR 第 1.2.2 节 | 47 天 | 域名和 IP 地址验证 10 天 |
“复用期”这一列容易被忽略,对自动化的影响却不小。CA 签发证书前要确认你确实控制这个域名,在复用期内,它可以沿用上一次的验证结果,不必重新验证。2029 年 3 月 15 日以后复用期只剩 10 天,两次签发如果相隔超过 10 天,就要重新完成域名验证。Let's Encrypt 在 2028 年给 classic 配置定的授权复用期更短,只有 7 小时。
BR 同一节还写明,自 2026 年 3 月 15 日起,主体身份信息(Subject Identity Information)验证数据的最长复用期为 398 天,这一项和域名验证分开计算。
为什么一张 SSL 证书不能再用一年
因为 2026 年 3 月 15 日起签发的证书最长只能用 200 天,不到一年。这个上限出自 CA/B Forum 在 2025 年 4 月通过的 SC-081v3 投票。
按照CA/B Forum 的 SC-081v3 投票页面(2026 年 10 月 29 日查阅),这份提案要把证书最长有效期从 398 天最终缩短到 47 天,从 2026 年 3 月开始,到 2029 年 3 月结束。398 天比一年稍长,现在的 200 天只有半年多一点,这就是单张证书有效期不再能达到一年的直接原因。
投票于 2025 年 4 月 4 日 19:30(UTC)开始,4 月 11 日 19:30(UTC)结束。证书签发方(Certificate Issuers)25 票赞成、0 票反对、5 票弃权,证书使用方(Certificate Consumers)4 票赞成、0 票反对。同一份提案还把 SAN 域名验证数据的复用期从 398 天逐步缩短到 10 天,非 SAN 验证数据则从 825 天缩短到 398 天。
Let's Encrypt 证书从 90 天缩短到 45 天的时间表
Let's Encrypt 会分阶段把证书有效期缩短到 45 天,每一步都比 BR 同期的上限更短。其中 2026 年的调整只针对主动选择 tlsserver 配置的用户,默认的 classic 配置从 2027 年开始变化。依据是 Let's Encrypt 的官方公告(2026 年 10 月 29 日查阅),公告标题说的就是从 90 天到 45 天。
- 2026 年 5 月 13 日,按公告计划,tlsserver 配置开始签发 45 天证书。这是一个可选配置,需要在 ACME 客户端里主动选择。
- 2027 年 2 月 10 日,默认的 classic 配置改为签发 64 天证书,授权复用期为 10 天。客户端里没有指定配置的话,用的就是 classic。
- 2028 年 2 月 16 日,classic 配置改为签发 45 天证书,授权复用期为 7 小时。
对照上一节的表格,64 天低于 2027 年起的 100 天上限,45 天也低于 2029 年起的 47 天上限。使用 Let's Encrypt 的站点,真正要关注的是 Let's Encrypt 自己的日期,等 BR 的节点到来时,它早已提前满足了要求。
用“SSL证书查询”查看证书的签发和到期时间
在“SSL证书查询”中输入“主机”和“端口”,结果里的“发布于”和“到期于”就是证书的起止时间。具体步骤如下。
- 打开 SSL证书查询 工具页面。
- 在“主机”里填写域名,例如 www.example.com。直接粘贴完整网址也可以,工具会从中提取主机名。
- “端口”默认是 443,普通 HTTPS 网站保持不变即可。服务运行在其他端口上时,改成对应的端口号。
- 点击“提交”。
- 在结果中查看“发布于”和“到期于”,记下到期时间。
拿到这两个时间后,可以做两件事。一是用“到期于”减去今天,得到剩余天数。二是用“到期于”减去“发布于”,算出这张证书的总有效期,看看你的 CA 实际签了多长,再对照上面的时间表判断下一张会不会更短。
结果里的“组织”和“常见名称”显示的是签发证书的机构信息,不是网站自己的名称。另外,查询从 Digily 的服务器发起,连接超时为 10 秒。只能在内网访问的主机,或者没有对外开放该端口的服务,查不到结果属于正常情况。
如果你给短链接或链接主页用了自己的域名,也可以用同样的方法查看这个域名当前返回的证书。域名接入的步骤见《把自己的域名接入 Digily Link》,DNS 记录的设置见A 记录与 CNAME 记录的自定义域名连接文档,本文不再展开。
“状态”显示绿色对勾不代表证书链没有问题
“状态”显示绿色对勾,只表示当前时间在证书有效期内,并不代表证书链和域名都通过了浏览器校验,也不代表证书没有被吊销。显示红色叉号,说明当前时间不在“发布于”和“到期于”之间,也就是证书已经过期或者尚未生效。
工具读取证书时没有开启证书链校验和主机名校验,也接受自签名证书。这样无论证书是否受信任,日期都能读出来。代价是自签名证书、缺少中间证书的证书链、证书上的域名与访问的主机名不一致,这几种情况都可能照样显示绿色对勾。
如果访客的浏览器报证书错误,而工具显示一切正常,就要另外检查证书链。可以在浏览器地址栏点开证书详情,看签发路径是否完整、证书覆盖的域名里有没有当前访问的主机名。也可以用 openssl s_client 之类的命令行工具,查看服务器在握手时实际发出的证书,再结合证书链和主机名校验的结果判断问题。
443 和 8443 端口可能返回不同的证书
这种情况确实存在。同一台主机的不同端口可以由不同的服务或不同的配置提供,各自挂的证书也可能不一样。举一个假设的例子,主站在 443 端口,管理后台在 8443 端口,主站的证书刚续过,后台那张却快到期了。所以查到期日时,每个对外提供 HTTPS 的端口都要单独查一次,不能只看 443。
证书有效期缩短后如何安排续期
最稳妥的做法是全程自动续期,并且按证书剩余寿命触发,而不是按固定天数触发。Let's Encrypt 在上面那篇公告里给出了几条建议,整理如下。
- 用自动续期,不靠手动。Let's Encrypt 不建议手动续期。有效期缩到 45 天后,手动操作漏续的风险会明显增大。
- 客户端支持的话,启用 ARI。ARI 全称 ACME Renewal Information,是 Let's Encrypt 首先推荐的方式,让续期时间跟着 CA 提供的续期信息走。
- 没有 ARI 时,不要用固定 60 天的间隔。Let's Encrypt 明确表示这个间隔不够,应该在证书寿命约三分之二时续期。比如一张 45 天的证书如果每 60 天才续一次,中间会有 15 天处于过期状态。
- 确认自动化能适应更短的周期。除了续期命令,域名验证、新证书部署和服务重载也都要能在更短的周期里稳定完成。2029 年复用期缩到 10 天后,验证这一步几乎每次都要重新走一遍,依赖手动添加 DNS 记录的验证方式会成为瓶颈。
- 为续期失败设置告警。续期失败时要有人第一时间收到通知,不能等证书过期、访客看到报错才发现。
按比例续期还能自动适应新的上限。比如你今天拿到的是 200 天证书,下次续期如果落在 2027 年 3 月 15 日之后,新证书最长只有 100 天,三分之二处就从第 133 天左右提前到第 67 天左右。脚本按“剩余有效期不超过总有效期的三分之一”判断,就不用在每个节点手动改配置;写死固定天数的脚本,则要在每个节点前检查一遍。
如果暂时只能手动续期,至少把三分之二的时间点记进日历。每次续完,再用“SSL证书查询”确认“发布于”已经变成新的日期。如果新证书已经签好、服务器却还在发旧证书,可能是部署后没有重载服务。
按三分之二规则推算续期日期的两个示例
用“发布于”加上有效期的三分之二,就能得到大致的续期日。下面两张证书的日期都是虚构的示例,按自然日粗算,实际以证书上记录的精确时间为准。
| 示例 | 发布于 | 有效期 | 到期于(约) | 三分之二处(约) | 届时剩余 |
|---|---|---|---|---|---|
| A,200 天证书 | 2026 年 11 月 1 日 | 200 天 | 2027 年 5 月 20 日 | 第 133 天,2027 年 3 月 14 日 | 约 67 天 |
| B,45 天证书 | 2026 年 11 月 1 日 | 45 天 | 2026 年 12 月 16 日 | 第 30 天,2026 年 12 月 1 日 | 约 15 天 |
示例 A 的续期日恰好落在 2027 年 3 月 15 日的前一天。如果续期推迟到这一天或之后才完成,拿到的新证书最长只有 100 天,下一次续期要排在新证书签发后第 67 天左右。规划时别默认下一张证书还是 200 天。
示例 B 说明了固定 60 天间隔的问题。从 2026 年 11 月 1 日起算,60 天后是 2026 年 12 月 31 日,而证书在 12 月 16 日前后就到期了。按三分之二规则在 12 月 1 日左右续期,还能留出大约 15 天的余量,用来处理验证失败或部署出错。
想马上知道自己网站的证书还剩多少天,可以用 SSL证书查询 查看证书到期时间,把“发布于”和“到期于”填进上面的表格,算出你自己的续期日。