TLS 证书的有效期正在迅速缩短——这改变了每个组织处理续订、验证和故障预防的方式。Let’s Encrypt 已确认将从 90 天证书转为 45 天证书（分阶段推出），并大幅缩短授权重用窗口。同时，CA/Browser Forum 的投票 SC-081v3 采用了更广泛的行业计划，最终将公共 TLS 证书的有效期限制在 2029 年 3 月 15 日之前的 47 天。
对于管理数十个——或数千个——证书的团队来说，真正的故事不是“更短的证书”。而是 更高的续订速度、更紧的验证重用，以及更小的操作错误余地。 网站监控和警报变得不可妥协。
SSL/TLS 证书有效期有什么变化？
45 天政策（Let’s Encrypt）
Let’s Encrypt 目前发放有效期为 90 天的证书，并将在 2028 年之前将其缩短至 45 天。这不是突然的“开关翻转”。Let’s Encrypt 正在分阶段推出，使用 ACME 配置文件：
日期 | 变更 | 授权重用 | 受影响的配置文件 |
|---|---|---|---|
2026 年 5 月 13 日 第一阶段 | 选择加入 tlsserver 配置文件发放 45 天证书 | 30 天（不变） | 早期采用者/测试 |
2027 年 2 月 10 日 第二阶段 | 默认 经典 配置文件转为 64 天证书 | 减少至 10 天 | 所有未使用 tlsserver 或 shortlived 的用户 |
2028年2月16日 第3阶段 | 默认 经典 配置文件转为 45 天证书 | 减少至 7 小时 | 所有使用默认配置文件的用户 |
关键要点
授权重用期与证书的有效期同样重要。它是可以重用先前域控制验证以颁发额外证书的时间窗口。Let’s Encrypt 将在 2028 年将此时间从 30 天减少到仅 7 小时——使可靠的 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月及以后 | 苹果对2020年9月1日后颁发的证书实施398天的最大限制；不合规的证书会导致连接失败 |
90天 | Let’s Encrypt规范（2014–2027） | Let’s Encrypt 建立了 “自动化原生” 的期望；Chrome 的安全团队强调了自动化以提高敏捷性和韧性 |
45 / 47 天 | 2028–2029 目标 | Let’s Encrypt 达到 45 天（2028 年 2 月 16 日）；CA/B 论坛将行业上限设定为 47 天（2029 年 3 月 15 日） |
45 天证书变更的行业影响
这并不是 Let’s Encrypt 独有的变化。Let’s Encrypt 明确表示，它正在 “与整个行业一起” 根据 CA/浏览器论坛的基础要求进行调整，所有公开信任的 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
- Webhooks
可自定义的警报阈值意味着您在恰当的时间收到警告——不会太早导致警报疲劳，也不会太晚以防止停机。每个警报清楚地标识证书、域名和推荐的操作。
隐藏的风险：续订后的部署漂移
续订成功并不等于部署成功。在分布式环境中，这两种状态经常会出现偏差。这种偏差被称为 部署漂移——它是最被低估的 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、SMS 警报 | 通过正确的渠道立即联系到合适的人 |
自动化定期报告 | 准备审计的导出，包含颁发者、链、算法和错误详情 |
边缘、CDN 和负载均衡器支持 | 监控部署漂移最常发生的确切层 |
集中式多域仪表板 | 为管理数十或数百个证书的团队提供单一视图 |
常见问题：Let’s Encrypt 45天证书到期
tlsserver ACME配置文件将于2026年5月13日开始，默认的classic配置文件将在2028年2月16日达到45天。变更将在每个生产日期前大约一个月部署到暂存环境。