TLS 证书有效期正在快速缩短 —— 这改变了每个组织处理续订、验证和故障预防的方式。Let’s Encrypt 已确认将从 90 天证书转为 45 天证书（分阶段推出），并大幅缩短授权重用窗口。同时，CA/浏览器论坛的投票 SC-081v3 采用了更广泛的行业时间表，到 2029 年 3 月 15 日最终将公共 TLS 证书期限限制为 47 天。
对于管理数十张甚至数千张证书的团队来说，真正的变化不是“更短的证书”，而是更高的续订速度、更严格的验证重用，以及运营错误的更小容忍度。网站监控和告警变得不可或缺。
SSL/TLS 证书有效期有什么变化？
45 天政策（Let’s Encrypt）
Let’s Encrypt 目前签发有效期为 90 天的证书，计划在 2028 年前将期限缩短到 45 天。这不是突然“开关翻转”的动作。Let’s Encrypt 正通过ACME 配置文件分阶段推出：
日期 | 变更 | 授权重用 | 受影响的配置文件 |
|---|---|---|---|
2026 年 5 月 13 日 阶段 1 | 选择加入的 tlsserver 配置文件签发 45 天证书 | 30 天（不变） | 早期采用者／测试 |
2027 年 2 月 10 日 阶段 2 | 默认 classic 配置文件转为 64 天证书 | 缩短至 10 天 | 所有未使用 tlsserver 或 shortlived 的用户 |
2028 年 2 月 16 日 阶段 3 | 默认 classic 配置文件改为 45 天证书 | 缩短至 7 小时 | 所有默认配置文件用户 |
关键要点
授权重用期与证书有效期本身一样重要。它指的是先前域名控制验证可被重用以签发额外证书的时间窗口。Let’s Encrypt 将把此期限从 30 天缩短至 7 小时（2028 年前） —— 这使得可靠的 ACME 自动化成为必需，而非可选。
行业基线：47 天（CA/浏览器论坛）
CA/浏览器论坛的投票 SC-081v3 引入了分阶段计划，将公共 TLS 证书最大有效期缩减为200 天（2026 年）、100 天（2027 年）和47 天（2029 年）。
Let’s Encrypt 的“45 天”与行业的“47 天”最大值完全兼容 —— Let’s Encrypt 计划比 CA/B 论坛的要求提前一年达到这一最终状态。
为何要缩短证书有效期？
缩短有效期是出于安全和韧性的考虑，驱动因素包括四个相互关联的目标：
- 缩小泄露影响范围：如果私钥被盗或证书被错误签发，更短的有效期限制了证书被滥用的时间。
- 更有效的撤销生态：短有效期减少了对撤销必须完美实施的依赖，Let’s Encrypt 指出更短有效期让撤销技术更高效。
- 减少陈旧验证数据：CA/B 变更还缩短了域名和 IP 验证的重用时间 —— 至 2029 年 3 月降至 10 天。
- 推动自动化与敏捷：浏览器和根证书程序明确鼓励自动化，因为它可以实现短生命周期，减少停机且更快速提升安全性。
证书有效期缩短时间线
以下是从 825 天缩短至 45 天的实际故事线：
最大有效期 | 时代 | 关键驱动因素 |
|---|---|---|
825 天 | 2020 年前的遗留最大值 | 无强制行业上限 |
398 天 | 2020年9月起 | 苹果强制实行398天的证书最长有效期，适用于2020年9月1日之后颁发的证书；不合规证书会导致连接失败 |
90 天 | Let’s Encrypt 规范（2014–2027） | Let’s Encrypt 建立了“自动化原生”的预期；Chrome的安全团队强调自动化以提升敏捷性和弹性 |
45 / 47 天 | 2028–2029 目标 | Let’s Encrypt 在2028年2月16日达到45天；CA/B论坛将行业上限定为47天（2029年3月15日） |
45天证书变化对整个行业的影响
这不仅是Let’s Encrypt的变动。Let’s Encrypt 明确表示，它正“与整个行业同步”遵循CA/Browser论坛的基线要求，所有公开受信任的CA都会做出类似调整。
这对Let’s Encrypt和其他CA的影响
- 续期速度成为默认操作模式：到2029年，组织实际上处于持续的续期周期中——尤其是在大规模环境下。
- 验证重用大幅缩减：域名和IP验证的重用计划在2029年3月降至10天，使得手动或偶尔处理的过程变得脆弱。
- ACME和续期智能更为重要：Let’s Encrypt 建议使用ACME续期信息（ARI），让客户端知道何时续期，并警告硬编码的续期间隔（如“每60天”）在45天周期下会失效。
- 新验证方法正在出现：Let’s Encrypt 正在开发DNS-PERSIST-01，以减少频繁域名验证的操作负担，允许持续的DNS TXT记录——预计2026年推出。
45天证书带来的运营挑战
45天证书不仅意味着“续期频率翻倍”。它们从根本上改变了失败模式：
- 错误缓冲期更短：一次错过续期窗口可能迅速导致用户面临停机。
- 更多环节参与：负载均衡器、CDN、Kubernetes入口、服务网格、API网关和传统设备可能都需协调更新。
- 验证摩擦增加：到2028年，Let’s Encrypt 经典配置的授权重用时间缩短至仅7小时，DNS/HTTP挑战自动化必须可靠——不能只是“尽力而为”。
- 清单盲点：大部分故障发生在“被遗忘”的证书上——生产前测试环境升级为生产环境、旧子域名、合作伙伴管理的域名，或者嵌入设备和中间件中的证书。
- 变更管理负担增加：更频繁的证书轮换提高了配置错误的风险：错误链、不完整链、主机名不匹配，或仅部署部分节点。
由于许多失败模式发生在证书颁发后——传播、重载、边缘缓存或部分部署期间——团队应增加外部验证：确认真实客户端生产环境收到的证书，而非仅凭内部日志。
为什么证书到期监控至关重要
Let’s Encrypt本人建议使用SSL监控工具进行充分监控，以便在证书未如期续期时及时提醒。实际上，监控能捕获：
- 续期自动化的隐性失败；
- 因重新签发导致的“非周期性”证书过期；
- 链或颁发者变更；
- 主机名不匹配和不完整部署。
如果缺乏适当的监控，SSL证书可能导致浏览器显示“您的连接不私密”的警告，SEO排名一夜下降，甚至阻止访问网站。这些后果既即时又可衡量——在45天证书大约每30天续期一次的情况下，捕捉隐性失败并防止用户可见中断的窗口明显缩小。
🔍 Dotcom-Monitor如何保持您的证书有效
Dotcom-Monitor的SSL证书监控作为智能全天候证书检测器，从30多个全球地点定期检查。一旦添加域名，平台就开始以全球真实用户体验的方式验证证书——执行完整的TLS握手，而不仅是简单的ping。
针对每个被监控的域名或端点，平台自动验证：
- 证书链完整性及颁发者正确性；
- 有效期和剩余天数倒计时；
- SAN和主机名一致性；
- 潜在的不匹配、无效响应或不受信任的颁发者；
- 所有监控设备的配置健康状况。
所有结果汇总于实时集中仪表板，支持智能排序和过滤——无论管理少量域名还是数百个，都能让团队在问题恶化前识别出故障。
45天证书周期下的自动化风险
更短的证书生命周期增加了续期事件频率，随之而来的是自动化失败的概率。在45天周期内，即使是细微的操作弱点也会更快更频繁地暴露。
为什么仅靠自动化在45天周期内更容易失效
最常见的失败点包括：
- DNS-01记录传播比预期慢；
- HTTP-01挑战被CDN或WAF拦截；
- 错误配置的防火墙策略阻止验证；
- ACME重试时触发速率限制；
- 容器重启时丢失证书目录；
- systemd计时器无声失败；
- 负载均衡器从未重新加载更新的证书。
重要提示：
这些问题本身并不是新问题——而是变得紧急的问题。当续期频率翻倍时，遇到这些情况的概率相应增加。自动化依然关键，但如果没有外部检测，则对部署生命周期的后段毫无察觉。
🔍 Dotcom-Monitor如何检测续期失败
当ACME自动化无声失败——如systemd计时器未触发、DNS挑战超时、负载均衡器未重新加载——Dotcom-Monitor通过持续的外部验证发现问题。平台一旦检测到证书即将过期或已失效，立即发送通知，不论内部自动化日志显示何种状态。
警报通过您团队已用的渠道发送：
- 电子邮件
- 短信
- Slack
- Microsoft Teams
- PagerDuty
- Webhook
可自定义的提醒阈值确保您在恰当时机收到警告——既不会过早导致警报疲劳，也不会过迟无力阻止故障。每条警报都清楚标明证书、域名及推荐的操作。
隐藏风险：续期后的部署漂移
续期成功不等于部署成功。在分布式环境中，这两者经常分歧。这种差异称为部署漂移——是TLS失败模式中最被低估的一种。常见原因包括：
- CDN在源站更新后继续提供缓存的证书链；
- 多区域负载均衡器在一个区域更新，另一区域未更新；
- Kubernetes Pod未能重新加载更新的TLS密钥；
- 反向代理需要完全重启才能加载新密钥对；
- 边缘节点在滚动基础架构更新时滞后。
关键结论
在90天周期下，漂移是偶发事件。在45天周期下，除非有明确监控，否则漂移出现的概率统计上更高。更短的生命周期不仅增加续期频率——同时提升了分布式系统中传播风险。
为何外部证书监控是最可靠的独立校验
内部系统关注续期流程，外部系统关注用户体验。这两者在许多情况下会分歧。内部监控能确认ACME客户端运行、证书发放和写入磁盘——但常常无法确认边缘是否正确提供证书、所有地区是否更新、或信任链完整。
外部监控以客户端方式验证证书：
- 执行完整的TLS握手；
- 检查链完整性；
- 验证SAN和主机名匹配；
- 检测意外的颁发者或链变更；
- 确认生产环境中的有效期。
关键结论
最重要的是，外部监控可从不同地理位置运行，有助于检测单一区域无法察觉的区域级漂移和CDN边缘不一致。外部验证是确保续期成功真正转化为正确生产交付的最可靠方式。
🔍 Dotcom-Monitor为何是您自动化体系所需的独立校验
Dotcom-Monitor在全球服务器检测您的证书，提供国际流量的准确结果，确保无论证书托管在哪里，持续的SSL监控都不会中断。该全球覆盖对于具有分布式基础设施的网站尤为重要——CDN边缘、多区域负载均衡器和Kubernetes集群——因为某些节点可能仍未从源站接收正确续期的证书。
平台支持对边缘网络、负载均衡器和CDN的监控——这些正是部署漂移最常发生的层级。它还支持定期全球报告（每日、每周或每月），汇总时间线、状态更新和所有监控设备的证书健康状况，减少人工工作，促进跨团队可视化。
对于合规要求高的组织，Dotcom-Monitor生成可导出的审计报告，包含证书详情、颁发者信息、信任链记录和错误日志——审计员常需的一切集中展示。
为短生命周期证书构建监控策略
45天证书周期需要的不只是简单的到期提醒。监控必须从“过期前提醒我”进化到“持续验证正确部署”。
从完整清单开始
大部分故障源自盲点。确保监控覆盖所有公共网站及子域、API和面向合作伙伴的端点、CDN边缘和源站服务器、对外暴露的内部网关、以及遗留基础设施和设备。未监控的端点是未管理的风险。
从多个全球位置监控
单一探针无法检测区域漂移、CDN边缘不一致性或ISP特定的信任链问题。全球验证确保链条在任何地方的正确性、区域间一致性以及边缘传播成功。Dotcom-Monitor从30多个全球位置进行检查，使这些多位置检查按计划重复且一致——在初始设置后无需任何手动操作。
验证不仅仅是过期
过期只是失败的一种模式。监控还应验证：
- 完整的信任链和正确的中间CA；
- SAN/主机名的准确性；
- 密码和协议兼容性；
- 意外的发行者变更。
触发续订后的验证
续订事件应自动启动即时的生产验证、多区域证书比较和链条校验检查。漂移通常在续订后立即出现，而不是在过期之前。
为45天生命周期使用分级警报
最终思考：在45天时代的监控与检测
短期证书提升安全态势。它们也压缩了操作容忍度，减少了检测配置或部署错误的时间窗口。自动化仍然是必不可少的——但没有验证的自动化在规模上变得脆弱。
45天时代的真正运营转变是：
- 续订是连续的；
- 验证重用窗口缩短；
- 部署漂移变得更频繁；
- 外部验证成为必需。
Dotcom-Monitor的SSL证书监控专为这种环境设计。它从全球30多个位置提供链条正确性、主机名对齐、过期状态和全球部署一致性的外部验证——通过实时警报发送至Slack、Teams、电子邮件、短信和PagerDuty。无论您管理单一域名还是数百个域名，该平台都能自动组织、跟踪并验证每个证书。
随着TLS生命周期在行业内缩短，检测和验证成为基础控制，而非可选的保护措施。Dotcom-Monitor提供了内部自动化无法单独实现的功能：
能力 | 解决的问题 |
|---|---|
30多个全球监控点 | 检测区域漂移和CDN边缘不一致性 |
完整TLS握手验证 | 确认真实用户接收到的内容，而非仅内部日志报告 |
链条与发行者验证 | 捕获不完整链、错误中间证书和意外的发行者更改 |
可自定义的过期警报阈值 | 分级警告在20、10、5天——为45天生命周期校准 |
Slack、Teams、PagerDuty、短信警报 | 通过正确的渠道即时触达合适的人 |
自动定时报告 | 符合审计要求的导出，包含签发者、链、算法和错误详情 |
支持Edge、CDN和负载均衡器 | 监控部署漂移最频繁发生的确切层级 |
集中式多域仪表盘 | 为管理数十或数百个证书的团队提供单一视图 |
常见问题：Let’s Encrypt 45天证书过期
tlsserver ACME 配置文件将于 2026 年 5 月 13 日 开始，默认的 classic 配置文件将在 2028 年 2 月 16 日 达到 45 天。更改将在每个生产日期前大约一个月部署到暂存环境。