证书有效期的缩短趋势
公开信任的 TLS 证书有效期，被浏览器厂商与 CA/Browser Forum 的政策持续压缩：2020 年起主流浏览器推动 398 天上限，之后又通过了分阶段继续缩短的计划。短有效期的好处是降低对吊销机制（OCSP/CRL）的依赖，代价是续期必须自动化，手工操作很快就会跟不上节奏。
基本信息
| 2020 年起 | 主流浏览器推动 398 天上限（公开信任 TLS 证书） |
|---|---|
| 后续计划 | CA/Browser Forum 已通过分阶段缩短方案，具体生效时间以官方公告为准 |
| 内网 PKI | 不受公开政策约束，但同类趋势同样适用 |
| 校验影响 | notBefore 与 notAfter 参与校验，客户端时间偏差会直接导致失败 |
| 自动化前提 | ACME 客户端或内部 CA 的接口化续期 |
| 监控 | 到期前分级告警，避免单点遗忘 |
典型使用场景
- 容量与排期规划：按有效期长度安排续期窗口与自动化改造
- 排查证书突然失效：先核对生效时间与客户端时钟
- 自动化改造：把续期接入 ACME 客户端或内部签发流程
- 合规评估：核对所用证书是否符合当前政策要求
- 内网 PKI 设计：为内部证书设定合理有效期与轮换路径
查看有效期与剩余天数
查看有效期与剩余天数
# 查看生效与失效时间
openssl x509 -in cert.pem -noout -startdate -enddate
# 判断是否在 30 天内到期：即将到期时返回非 0
openssl x509 -in cert.pem -noout -checkend 2592000
# 读取远端服务实际生效的证书时间
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates字段读法
| 字段 | 含义 | 异常表现 |
|---|---|---|
| notBefore | 生效时间，早于它校验失败 | 客户端时间偏差会造成误判 |
| notAfter | 失效时间，晚于它校验失败 | 到期即全量中断 |
| 剩余天数 | checkend 的判断依据 | 阈值告警的第一手数据 |
| 总有效期 | 政策约束的核心指标 | 超过政策上限的证书会被拒绝 |
有效期缩短后手工续期不现实：签发与部署必须流水线化，走 ACME 客户端或内部 CA 的接口完成。
checkend 返回非零的语义是「即将到期」，不是脚本错误；把它当作失败处理会让监控告警给出误导性结论。
时间问题跨越时区：团队分布在不同时区时，对到期时间的理解容易出现偏差，内部沟通与告警文案都建议统一使用 UTC 表述。