将内部服务的证书有效期统一管理至 90 天
针对内网及后端服务，建议建立以 90 天为周期的证书强制轮换制度。该规范核心是借助自动化监控和更新流程，消除因证书过期导致的非计划停机风险。本文阐述其具体实施要点，并界定其主要适用于证书颁发完全自主可控的内部环境，而对公网证书需结合CA策略另行规划。
本文目录
规范内容：强制 90 天证书生命周期
对于所有由内部证书颁发机构（CA）签发的，用于内部服务间通信、管理接口或测试环境的 TLS 证书，强制规定其最长有效期不得超过 90 天。该规范覆盖证书的申请、部署和吊销全流程，核心目标是通过高频次的、可控的轮换，杜绝因证书过期引发的生产故障。
为何选择 90 天？
这个周期是自动化运维便利性与管理开销的折中点。
- 足够短：能迫使团队建立或完善自动化证书管理流程。90天的周期意味着证书问题会在季度内暴露，留有充足的缓冲时间进行手动干预，而不像长期证书（1-2年）那样容易被遗忘。
- 足够长：避免了过高的轮换频率带来的系统负载和日志干扰，对自动化工具链和系统稳定性的要求相对平和。对于大多数内部服务，季度轮换是一个易于纳入运维节奏的周期。
关键实施步骤
- 统一签发入口：所有内部证书必须通过指定的内部CA或自动化平台（如 Vault PKI）申请。禁止使用自签名或来自外部公共CA的长期证书用于此类场景。
- 自动化监控与告警：在监控系统中，将证书过期时间（
Not After）作为关键指标。建议设置多级告警，例如：在证书到期前 60 天、30 天、7 天分别触发不同优先级的告警。监控脚本应遍历所有相关服务的证书。 - 自动化更新与部署：尽可能实现证书的自动续签与热加载（如 Nginx 的
reload）。对于无法热更新的系统，应将证书部署纳入标准的发布流程，并由监控告警驱动。 - 测试与回滚：任何证书更新都应先在测试环境验证，并记录标准的回滚步骤。确保更新证书不会影响 mTLS（双向TLS）对端的验证。
适用边界与限制
这项规范并非万能药，其有效应用依赖于特定前提。
强烈适用的场景：
- 内部服务网格：如微服务间的 mTLS 通信。
- 私有云和数据中心内部 API：管理员后台、监控系统入口等。
- 开发与测试环境：快速轮换有助于模拟生产环境并保持环境一致。
- 团队拥有完全的 CA 控制权：这是能实施强制轮换的根本前提。
需要谨慎或不适用的情况：
- 面向公网的用户服务证书：此类证书的生命周期受公共 CA（如 Let's Encrypt）策略和浏览器信任链影响。虽可效仿90天策略（如 Let's Encrypt 默认90天），但其管理需结合DNS验证、ACME客户端等公网特有流程，与纯内部管理有区别。
- 使用商业公共 CA 签发的内部证书：商业CA通常对证书最短有效期有要求，且续签流程可能涉及人工审核和费用。此类情况更适合制定独立的、以年为单位的管理策略，并辅以严密的到期监控。
- 老旧或无法自动化的系统：若系统不支持证书热加载或无法纳入部署流水线，强制短周期轮换可能引入过高的运维风险和成本。对此类系统，可考虑豁免，但必须实施比标准更严格的到期监控（如提前 90 天告警）。
- 短期临时证书：用于临时测试或活动的证书，其生命周期本身可能就短于90天，无需应用此规范。
结论：将内部证书有效期统一为 90 天，本质是一种以纪律和自动化换可靠性的运维实践。它通过建立强制的、可预测的节奏，将证书管理从被动的“救火”转变为主动的、常规的运维任务。成功推行此规范的关键，在于明确其适用边界，并投资于相应的自动化监控与更新工具。