证书有效期正在砍向47天，一年一换的续期流程撑不到2027年

摘要：公开信任的TLS证书最长有效期，已经在2026年3月15日从398天降到200天，2027年降到100天，2029年降到47天。真正会先咬到人的不是这条，是同一份表决里被顺带砍掉的域名验证数据复用期——它最终降到10天，意味着证书还没到期，你上次做的验证就已经不能再用了。与此同时，签发机构开始通过一个标准协议主动告诉客户端“该续了”，而Let's Encrypt在2025年8月关停了OCSP响应器，让全网教程里那行ssl_stapling变成了一句空话。

先给一个具体的日子：2026年3月15日。从那天起，任何一家公开信任的证书颁发机构，都不能再签发有效期超过200天的TLS证书。

如果你的续期流程是“每年提醒自己一次，登后台点一下续费，下载新证书扔到服务器上”，那么这套流程在那一天已经正式作废了。它不会立刻炸——你手上那张老证书还能用到到期——但它下一次轮转时，间隔会突然缩短到不足七个月，再下一轮不足四个月。

更值得注意的是，这不是终点。整条时间表已经排到2029年，而中间还夹着一条几乎没人讨论、却比有效期本身更难受的变化。

一年一换的流程，是从哪一天开始不成立的？

表决本身：全票通过，零反对

这项变更来自CA/浏览器论坛第SC081v3号表决《引入有效期与数据复用期缩减时间表》，通过时间是2025年4月11日。提案人是苹果的Clint Wilson，联署方包括Sectigo、Google Chrome和Mozilla。

票型值得看一眼：证书签发方25票赞成、0票反对、5票弃权；证书消费方（也就是浏览器厂商那一侧）4票赞成、0票反对。零反对票的意思是，这件事没有任何谈判空间，也不会被推翻。

三个日期，三个数字

最后一行的47是个看着有点怪的数字。业界普遍引用的拆法是：一个月（31天）＋半个月（15天）＋1天缓冲。这个设计意图很直白——让证书的轮转周期短到人工流程根本跟不上，从而逼迫整个生态走向自动化。

还有个容易踩空的细节：DigiCert关于47天有效期正式落地的说明里提到，签发方实际会把产品上限压在规则线之下一点点——200天那一档按199天签。原因是有效期计算涉及时区与签发瞬间的微小延迟，卡在整数上有极小概率越界，而越界的后果是这张证书不合规、必须吊销重签。做容量规划时按199算，别按200。

为什么要缩短

公开的理由主要有两条。一条是吊销机制在实践中基本失效：浏览器对吊销检查普遍采用软失败策略，查不到就放行，所以一张被吊销的证书在很多客户端上依然畅通无阻。既然吊销不可靠，那就靠缩短有效期来限制损害窗口。

另一条是加密敏捷性：算法要迁移、密钥要轮转、根证书要更替，而这些动作的速度上限，就是全网证书的最长有效期。

换个角度看这件事：证书有效期从来不是给你用的，它是这个体系给自己留的纠错窗口。窗口越短，一次失误的代价越小。

被忽略的另一半：域名验证数据能复用多久？

这一节是这篇文章最想让你记住的部分。绝大多数关于47天的讨论都只讲了有效期，而同一份表决里还有另一组数字。

两条并行的削减线

表决原文里列的方向性目标有三条：非SAN类验证数据从825天降到398天；SAN类验证数据从398天降到10天；证书最长有效期从398天降到47天。

第二条是关键。SAN指的就是证书里那些域名条目，SAN类验证数据说的是“你证明过自己控制这个域名”这件事能被记多久。以前这个记忆是398天——一年之内你续多少次证书，都不用再证明一次。

10天意味着什么

意味着即便证书还有效期，只要距离上次域名验证超过了复用窗口，续期时就必须重新完成一次域名控制验证。对使用ACME协议的自动化流程，这只是多一轮HTTP或DNS挑战，客户端自己就办了。

对手工流程，这是灾难性的。你不再是“下载一个新文件替换旧文件”，而是每一次续期都要重新过一遍验证——放DNS TXT记录、等生效、点验证、再签发。而这套动作在47天周期下一年要做八次。

手上到底有多少张证书，很多人答不上来

在讨论怎么自动化之前，有个更基础的问题：你知道自己名下有几张公开信任的证书吗？

这个问题比听上去难回答。证书可能来自主机商赠送、CDN自动签发、某个同事在某个平台单买、开发环境留下的临时证书、以及早年买的多年期产品。它们分散在不同账号、不同邮箱、不同控制台里。

有一个免费且相当彻底的盘点方法：证书透明度日志。所有公开信任的证书在签发时都必须记入CT日志，也就是说任何一张给你的域名签发过的证书，都在一个公开可查的地方留着记录。在CT日志查询服务里输入你的主域名，能一次看到全部历史签发记录，包括那些你已经忘掉的子域名。

这个动作往往能翻出两类东西：一类是早已废弃但证书还在自动续的老子域名，一类是你完全不知道存在的签发记录——后者需要认真查一下是谁签的。

判据只有一条

可以用一句话判断你的流程会不会被这轮变化打死：如果续期过程里有任何一步需要人打开浏览器，这套流程的寿命就是确定的。不是会不会出事的问题，是哪一次出事的问题。

保哥去年帮一个做家居灯具的客户梳理证书清单，翻出来十一个域名，其中三个是市场部同事早年自己在某平台买的、绑在个人邮箱上、每年手动续。这三个域名分别指向一个落地页、一个法语站和一个客服系统。按当时的续期方式，2027年之后每年要重复三十二次这套动作，而记着这件事的人已经离职了。

证书正在变成一次性用品吗？

如果47天听起来已经够激进，看看这条线的另一端在发生什么。

6天有效期已经正式可用

Let's Encrypt关于6天证书与IP地址证书正式全量开放的公告发布于2026年1月15日。这类证书的有效期是160小时，也就是6天多一点。它不是实验品，是普遍可用的正式产品，走的是ACME客户端里一个叫shortlived的证书配置档，选一下就行。

时间线上它比47天的规则跑得更靠前：2025年2月签出第一张，4月对早期采用者开放，2026年1月正式全量。也就是说在规则要求47天的三年前，6天证书就已经能用了。

为什么会有人要6天的证书

核心理由和缩短有效期是同一条：吊销机制不可靠。一张6天的证书，就算私钥泄露了也只有6天的窗口，而且这个保护是自动生效的，不依赖任何客户端去查吊销状态。

顺带解决的还有一件事：同一份公告里提到，Let's Encrypt开始为IP地址签发证书了。这是它历史上第一次做这件事，对做接口服务、边缘节点、临时环境的场景挺实用。

你该不该现在就切过去

大概率不该，但理由值得说清楚。6天证书对自动化的要求是另一个量级——续期链路里任何一环卡住超过一天，你就已经用掉了六分之一的缓冲。90天证书能容忍一次续期失败，6天证书不能。

合理的用法是把它当成一次压力测试：如果你的流程能扛住6天周期，那么它一定能扛住47天。反过来，如果你连想都不敢想6天，那说明流程里还有需要人参与的环节，而那个环节就是你未来两年要拆掉的东西。

顺带把告警阈值改成比例

很多人的监控告警沿用了一个旧习惯——到期前30天提醒。在398天时代，30天占7.5%，是个合理的缓冲。到了47天时代，30天占64%，意味着证书刚签出来两周多就开始报警，告警会迅速变成噪音，然后被静音。6天证书上这个阈值更是直接失去意义。

合理的做法是把阈值改成按比例算，比如剩余寿命低于三分之一时提醒。这条改动很小，但它决定了你的告警在两年后还有没有人看。

上限是200天，那大家实际在用多少天？

这个问题在所有讨论47天的文章里都没人问，而它的答案会让你对整件事的判断彻底改变。

6个站点的实测结果

保哥在2026年7月直接用openssl s_client拉了6个站点当时正在服役的证书，读出签发时间和到期时间：

规则允许200天，实测6个站里5个是90天，剩下一个107天。没有任何一个用满上限，连一半都没用到。

这组数字真正说明的事

200天这个上限，在真实世界里根本不是约束条件。已经跑ACME自动化的站点，早在规则收紧之前就自发把周期压到了90天左右——因为对一台会自己续期的机器来说，续得频不频跟人没关系，而周期短意味着出问题时暴露窗口小。

于是这轮缩短的真实含义就浮出来了：它对已经自动化的人是零影响，它精确地、只打击还在手工续期的那一批。这不是副作用，这就是设计意图——用规则把最后那批不肯自动化的人清出去。

顺带看stripe.com那一行。DigiCert是典型的商业CA，客户里有大量还在走采购流程的企业，而它给出的实际有效期是107天——已经踩在2027年那一档的门槛上了。连最保守的那一侧都已经提前落位，说明整个行业对时间表的信心相当足。

一个能顺手看出签发方风格的小细节

把上面几张证书的时间精确到秒去看，会发现两种风格：Let's Encrypt和Google Trust Services的时间戳带着具体的时分秒，是签发那一瞬间；Sectigo和DigiCert的则是整齐的00:00:00到23:59:59，按自然日对齐。

这个差别本身无害，但它会影响你算剩余天数的方式。按自然日对齐的证书，实际可用时间会比你算出来的多出不到一天；按签发瞬间的证书则一秒不多。在398天时代这点误差可以忽略，在47天时代它占了2%，写监控阈值时值得留意。

谁来决定这张证书什么时候续？

答案在2025年正式变了，而且变得比大多数人意识到的更彻底。

ARI把决定权交给了签发方

ACME Renewal Information扩展已经在2025年9月作为RFC 9773标准文档正式发布。它做的事情用一句话说就是：你的ACME客户端不再自己决定什么时候续期，而是去问签发机构。

机制很简单。客户端定期请求一个renewalInfo端点，拿回一个suggestedWindow，里面是一个开始时间和一个结束时间：

{
  "suggestedWindow": {
    "start": "2026-02-03T04:00:00Z",
    "end":   "2026-02-04T04:00:00Z"
  }
}

客户端的正确行为是在这个窗口里随机挑一个时刻去续，而不是掐着开始时间一拥而上。Let's Encrypt返回的Retry-After是21600秒，也就是6小时，客户端应当按这个间隔重新轮询。

这不是便利性功能，是应急通道

ARI真正的设计目的容易被误解成“帮你省心”。它的核心用途是批量吊销事件。

假设某家CA发现自己签发流程里有缺陷，按规则必须在24小时内吊销一批证书。在ARI出现之前，这意味着几百万个站点在同一天集体挂掉，而且它们的续期脚本还在按自己的老日程慢悠悠地等。有了ARI，CA可以提前把这批证书的建议窗口整体前移，让客户端在吊销发生之前就悄悄换好新证书。

签发方的公开说明里举过Shopify这类需要为数百万商户自定义域名维护证书的场景，这也是ARI最能体现价值的地方——没有全局协调的话，海量续期请求会挤成一个尖峰，而那个尖峰本身就是一次事故。

窗口内随机取值这条要求不是客套

RFC里对客户端行为写得很明确：拿到窗口之后要在其中随机挑一个时刻，而不是一到窗口起点就发请求。这条要求经常被实现者当成建议忽略掉，但它是整个机制能不能成立的前提。

道理不难理解。签发方之所以给的是一个窗口而不是一个时刻，就是为了把负载摊开。如果所有客户端都掐着起点发请求，那么窗口的宽度等于零，尖峰照旧——随机化不是优化，它是这个设计能工作的必要条件。

顺带说一句自己写脚本时的坑：很多人用cron的固定分钟数来跑续期，比如每天凌晨3点整。全世界用同一个教程的人，都在3点整。这跟ARI想解决的问题正好是反的。加一行随机sleep的成本几乎为零，但它决定了你是那个尖峰的一部分，还是被摊平的那部分。

你要做的只有一件事

确认你的ACME客户端版本足够新并且启用了ARI。Certbot从4.x起默认检查renewalInfo端点，一旦拿到窗口，就会覆盖它自己那条“剩30天才续”的老规则。acme.sh、lego、Caddy内置的证书管理也都已支持。

需要留意的是频率：ARI要求客户端定期轮询，而不是一天跑一次就完事。很多人的cron写的是每天凌晨三点跑一次certbot renew，在47天时代这个频率偏低，建议改成每天两到四次，并加上随机延迟避免整点集中。

# 每6小时跑一次，并随机延后0到3600秒
0 */6 * * * sleep $((RANDOM \% 3600)) && certbot renew --quiet

把这条接进服务器的定时任务体系时，可以参考用cron把独立站服务器运维自动化那篇里备份、缓存、证书几件事的编排顺序。

nginx里那行ssl_stapling，2025年8月之后还在做什么？

答案是：什么都不做，而且不报错。

OCSP整个退场了

Let's Encrypt关于2025年终止OCSP支持的公告给出的时间表分三步：2025年1月30日起，除非账户此前签发过带OCSP Must-Staple扩展的证书，否则带该扩展的签发请求一律失败；2025年5月7日起，所有带该扩展的请求失败（包括续期），同时证书里的OCSP地址被移除、换成CRL地址；2025年8月6日，OCSP响应器彻底关停。

停用的理由是隐私。公告里的说法是，当访客的浏览器通过OCSP查询证书吊销状态时，运营响应器的那家CA就立刻知道了这个IP正在访问哪个网站。这个副作用存在了很多年，只是一直被当成可以接受的代价。

那行配置现在的行为

全网2020年前后的nginx教程里，几乎都有这么两行：

ssl_stapling on;
ssl_stapling_verify on;

对Let's Encrypt签发的证书，这两行现在是空转的。nginx官方对ssl_stapling指令的说明里写明，装订所需的OCSP响应地址取自证书里的Authority Information Access扩展。证书里没有这个地址，nginx就无从装订，只会在错误日志里留下一条告警，然后照常提供服务。

所以这两行的实际状态是：不出错、不生效、不提醒。它是一段很典型的配置遗迹——所有人都抄，没有人验证过它还在不在工作。

删还是留

如果你的证书全部来自Let's Encrypt，删掉这两行，顺便把错误日志清干净。如果你还有商业CA签发的证书（部分仍提供OCSP），可以保留，但要意识到它的价值正在快速归零——整个行业都在往CRL和短有效期这个方向走，OCSP的退场只是时间问题。

顺带把老配置里其他几处一起看了：ssl_protocols里如果还留着TLSv1和TLSv1.1，删掉；ssl_session_tickets在单机场景建议关掉；HSTS的配置和preload提交流程可以对照HTTPS站点开启HSTS的配置与preload提交那篇复核一遍。

证书过期一小时，SEO要还多久？

这是独立站主最该关心的一节，因为它的账不是按小时算的。

证书过期的故障形态很特别

大多数线上故障会在服务器上留下痕迹：5xx日志、进程崩溃、负载飙高。证书过期不会。服务器完全正常，nginx照常返回200，是客户端在握手阶段就单方面终止了连接。你的access log里看不到这些失败的请求，因为它们压根没走到HTTP层。

爬虫这一侧的表现是抓取失败。连续的抓取失败会触发抓取速率下调，而这个下调的恢复是不对称的——降下来很快，涨回去要按周计。这个机制和服务器响应变慢时的表现类似，服务器变慢导致抓取速率被调低而日志里一条错误都没有那篇里描述的正是同一类“无声故障”。

HSTS会把损失放大

如果你开了HSTS，浏览器在证书出问题时不再提供“继续访问”的选项——这正是HSTS想要的效果，但它意味着证书过期期间你的站点对回头客是彻底不可达的，连绕过都做不到。

preload列表让这件事更彻底：即便是第一次访问的用户也会被拦下。开了HSTS preload的站点，证书自动续期就从“最好有”变成了“必须有”。

混合内容与跳转链的连带风险

换证书本身不改变协议，但很多人在处理证书问题时会顺手动跳转规则，这是另一个常见的翻车点。HTTP到HTTPS的跳转如果配成了链式（先跳www再跳https，或者反过来），每多一跳就多一份延迟和一次抓取消耗。跳转的正确写法可以对照HTTP与HTTPS双向301跳转的实战配置核一遍，多域名场景则看Nginx开启HTTPS后多域名301跳转到主域名的完整配置。

通配符、多域名和CDN，各自会卡在哪一步？

把自动化落到具体架构上，卡点其实就那么几处，而且每一处都有明确的解法。

通配符证书只能走DNS验证

这是ACME协议的硬约束：申请*.example.com这种通配符证书，唯一可用的验证方式是DNS-01，也就是往域名的TXT记录里写一个值。HTTP验证做不到，因为通配符覆盖的子域名是无限的，没法逐个放文件。

后果是通配符证书的自动化，必然依赖DNS服务商的API。如果你的域名托管在一个不提供API的地方，自动化这条路直接被堵死——在47天时代，DNS服务商有没有API，已经从一个便利性问题变成了架构选型问题。

典型配置长这样，以Cloudflare为例：

certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cf.ini \
  --dns-cloudflare-propagation-seconds 30 \
  -d example.com -d "*.example.com"

那个propagation-seconds参数经常被漏配。DNS记录写进去到全球可查有传播延迟，certbot默认等的时间对某些服务商偏短，验证会随机失败——而且是随机的，你重跑一次可能就过了，于是问题被当成偶发忽略掉，直到某次续期连着失败几回。

多域名证书的SAN条目有上限

一张证书可以覆盖多个域名，做法是把它们都写进SAN字段。多数CA的上限在100个左右。真正的问题不在数量，在耦合：SAN里任何一个域名验证失败，整张证书都签不出来。

所以一张塞了五十个域名的证书，等于把五十个独立的失败点串成了一条链。做站群或者多语言站的话，按业务边界拆成几张证书，比图省事塞成一张要稳得多。

CDN后面其实有两张证书

这一条最容易被忘掉。站点接了CDN之后，链路上有两段TLS：访客到CDN边缘一张，CDN回源到你服务器一张。

前者通常由CDN托管，自动续，你基本不用管。后者是你自己的源站证书，而很多人在配回源时选了“不验证证书”或者干脆挂了一张十年期的自签名证书，然后就再没看过它。

这张证书过期的故障表现是CDN回源失败，用户看到的是CDN返回的错误页，而你去查源站是好的、查CDN配置也是对的，排查方向很容易跑偏。把源站证书也纳入到期监控，是接CDN之后必须补的一课。这一层的边界划分可以对照Apache的htaccess六层治理里重写、缓存与HSTS的分工那篇，虽然那篇讲的是Apache，但分层的思路是通用的。

47天时代的续期流程该长什么样？

把前面的约束合起来，可以推出一套不依赖记忆力的流程。

四条硬要求

• 全自动：整个链路里不能有需要人操作的步骤，包括域名验证。这意味着DNS挑战要用API而不是手工加记录。
• 高频轮询：每天至少两次，配合随机延迟，让ARI的窗口有机会被及时看到。
• 装载后自动重载：新证书写盘之后必须触发服务重载，且重载失败要能被感知。
• 独立监控：到期监控不能跑在被监控的那台机器上，也不能依赖被监控的那张证书。

nginx侧的三个实操细节

第一，用reload不用restart。reload是平滑的，已有连接会被老进程处理完；restart会掐断所有在途连接。certbot的deploy hook里写这一行就够：

--deploy-hook "nginx -t && systemctl reload nginx"

注意前面那个nginx -t。没有语法校验的reload是危险的：配置有错时reload会失败，而nginx会继续用着旧配置和旧证书跑，直到旧证书过期。这个失败是静默的，除非你专门去看返回码。

第二，ssl_certificate指向certbot的live目录，那是一组符号链接，certbot每次续期只更新链接指向，nginx配置一个字都不用改。直接指向archive目录里的具体文件是常见错误，续期之后nginx还在读老文件。

第三，证书链要完整。fullchain.pem而不是cert.pem——后者只有站点证书，没有中间证书。桌面浏览器往往能自己补上中间证书所以看不出问题，很多移动端和命令行工具不会，这类故障的典型症状是“电脑上打得开手机上打不开”。

监控要怎么做才不会自己把自己关在门外

这条单独说，因为它是个很容易掉进去的逻辑陷阱：你把证书到期监控部署在自己的服务器上，用自己的域名做健康检查接口。证书一过期，监控服务本身第一个上不来，于是它没有报警。

这大概是运维界最标准的一次自锁门——钥匙就在屋里。

正确做法是把证书到期检查放在站点之外：用第三方监控服务，或者用一台完全独立的小机器跑一条定时任务。检查逻辑本身很简单：

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -enddate

把输出的到期时间和当前时间做差，低于剩余寿命的三分之一就告警。这条命令还有个附带好处：它走的是真实的TLS握手，所以证书链不完整、SNI配错、中间证书缺失这些问题它都能一起测出来，比单纯读本地文件的到期日靠谱得多。

照着这份表把迁移动作排完

最后给一份可以直接执行的清单，按优先级排序。

倒数第二行的验证方式值得特别执行一次。没有演练过的告警，跟没有告警在统计上是同一件事——这条经验在容器场景里同样成立，Docker发布端口后ufw规则形同虚设那篇讲的也是同一类问题：配置看起来生效了，但没有人从外面验证过。

还有一条容易被漏掉的：如果你的站点在CDN后面，证书其实有两张——CDN到访客那张，和源站到CDN那张。后者经常被设成十年有效的自签名证书然后就再没人管过，而它一旦过期，故障表现是CDN回源失败，排查方向很容易跑偏。服务器位置和CDN的关系可以顺带看看服务器放美国还是国内对Google排名的真实影响那篇里的分层拆解。

常见问题解答

47天是从2026年就开始执行吗？

不是。2026年3月15日起是200天，2027年3月15日起是100天，47天要到2029年3月15日才生效。但把迁移工作拖到2028年是危险的，因为100天那一档已经足以让手工流程崩溃，而且域名验证数据复用期的缩减是同步推进的，它比有效期更早开始咬人。

我用的是商业CA买的证书，也受这个限制吗？

受。这条规则针对的是所有公开信任的TLS证书，也就是所有能被主流浏览器默认信任的证书，跟你花多少钱买的没关系。只有私有CA签发的、仅在你自己内部信任的证书不受此约束。

把证书买成三年期，是不是就能躲过去？

躲不过。现在能买到的所谓多年期产品，本质是多年期的订阅额度，实际签发的每一张证书依然受当期有效期上限约束，到期后从订阅里再签一张。付费周期和证书有效期是两件事，很多人在这里理解错了。

启用ARI之后，续期会变得更频繁吗？

通常不会。正常情况下签发机构给出的建议窗口就落在证书寿命末段，跟你自己算的时间点差不多。ARI真正发挥作用是在异常情况下——比如需要批量吊销时，签发方会把窗口整体前移，让你在事故发生前就换好新证书。所以它更像一条应急通道，而不是日常的加速器。

OCSP停用之后，证书吊销还能被检查到吗？

能，走的是CRL。Let's Encrypt在移除OCSP地址的同时在证书里加入了CRL地址，主流浏览器有各自的吊销信息分发机制来消费这些数据。对站点运营方来说这一变化基本无感，唯一需要做的就是把配置里那行失效的ssl_stapling清理掉。

证书自动续期成功了，但网站还是用着旧证书，是什么原因？

最常见的是重载没有真正执行。certbot把新文件写好了，但deploy hook没配、或者hook里的配置校验失败导致reload被跳过，nginx依然拿着内存里的旧证书在跑。判断方法是比较磁盘上证书文件的到期时间和用openssl从443端口拿到的到期时间，两者不一致就是这个问题。次常见的是配置指向了archive目录里的具体文件而不是live目录的符号链接。

权威参考资料