证书最长有效期降到两百天那一档，续期和监控要先改哪几处
证书最长有效期降到两百天那一档，续期和监控要先改哪几处：先改自动续期的触发窗口、到期提醒的接收对象与渠道、部署层是否支持批量替换证书这三处，监控阈值另算一处，要从按周看改成按天看。过去按「一年换一次」设计的自动续期窗口、到期提醒和部署流程，现在都要按季度甚至更短的周期重排。
有效期缩短改变了什么
签发基线里的时间表已经明确：自 2026 年 3 月起订阅证书最长有效期为 200 天，2027 年 3 月降到 100 天，2029 年 3 月进一步降到 47 天。
对访问者来说没有可感知的变化，变化全在运维侧：
- 续期次数按倍数上升，人工续期不再可行；
- 一次续期失败的暴露窗口占比变大，同样的故障时间在短周期里占比更高；
- 证书与私钥的存放、替换流程会被频繁触发，任何手写步骤都会成为故障点。
三处先改，顺序有讲究
| 改动项 | 要调的具体参数 | 容易漏的坑 |
|---|---|---|
| 自动续期窗口 | 触发提前的天数、失败重试次数与间隔 | 只改提前天数，没改重试上限，短周期里来不及重试 |
| 到期提醒 | 提醒对象、渠道、提前量分级 | 提醒只发到某个人的邮箱，人不在就没人跟进 |
| 部署层替换 | 是否支持一次操作覆盖全部站点地址 | 多站点逐个手工替换，漏掉其中一个 |
先改续期窗口，再改提醒，最后改部署层。理由很简单：续期成功之后，替换动作与提醒才有意义。
提醒要发到哪里
站内已有邮件提醒能力，把到期提醒接进同一套通知里，比新建一条独立告警更容易被长期执行。配置时有两点：
- 提醒按剩余天数分级，例如还剩三十天与还剩七天用不同收件人，前者给运维，后者升级给负责人；
- 提醒内容要带上具体域名与到期时间，只写「证书即将过期」会在多站点场景里丢失定位信息。
部署层怎么配合
用面板或容器部署的站点，证书常被挂载或写死在配置片段里。有效期缩短后，「换一张证书改一个文件」的做法在多站点上会成倍放大工作量，需要确认部署方式是否支持批量替换站点地址与证书引用；不支持时，把证书路径统一成变量，让替换收敛到一处。
改配置之前先导一份备份，且备份范围要包含静态文件。短周期续期意味着更多次改动，而每一次改动都需要一条可退回的路径。
监控按天看
监控项从「有没有过期」改成「剩余天数是否在预期区间内」。如果续期任务连续几天没有成功记录，即使当前仍然有效，也已经是故障状态。
常见问题
四十七天那一档要现在就开始准备吗？ 按时间表它是 2029 年的要求，但真正要提前准备的是全自动链路：只要续期还依赖人工点一下，档位越低越容易出事。
有效期变短会影响搜索引擎抓取吗？ 不会直接影响。要防的是续期失败导致的访问中断，那种情况下页面不可达才会反映到收录上。
换证书后要不要重定向旧地址？ 不需要。证书更换不改变地址结构，只有站点搬迁或伪静态规则调整时才需要配 301 跳转。