证书生命周期管理：从签发到过期吊销的全流程
证书轮换这件事，很多人只盯着“换”的那一刻。但我做了这么多年安全架构，可以负责任地说——轮换只是生命周期的一个节点。真正决定轮换成败的，是前面几个月甚至几年的管理流程。
今天我们就来聊聊证书的完整生命周期。我习惯把它分成五个阶段：签发、部署、监控、预警、吊销。每个阶段都有坑，咱们一个一个说。
核心观点：证书轮换不是一次性操作，而是生命周期管理的自然结果。流程越规范，轮换越轻松。
1. 签发：一切从这里开始
签发是生命周期的起点。说白了，就是向 CA 申请一张证书。我个人习惯把签发流程分成三步：
- 生成密钥对——私钥必须安全保存，公钥随 CSR 提交
- 提交 CSR——包含域名、组织信息、公钥
- CA 验证并签发——验证域名所有权后，返回证书
这里有个细节很多人忽略：CSR 中的 CN（Common Name）和 SAN（Subject Alternative Name）。我记得有一次项目上线前，发现证书只签了主域名，所有子域名全部报错。嗯，从那以后我每次签发前都会检查 SAN 列表。
我的习惯：签发时就在证书备注里记录用途、负责人、到期日期。别等到轮换时再去翻日志，那太被动了。
2. 部署：证书装上去只是第一步
部署听起来简单——把证书文件放到服务器上，配置一下就行。但我在项目中遇到过太多次“部署成功但服务不可用”的情况。
部署时我建议检查这几项：
- 证书链完整性——中间证书有没有漏？很多报错都是因为只配了叶子证书
- 私钥权限——600 或 400，别让其他用户能读到
- 服务重载——Nginx 要 reload，Java 要重启，别搞混了
- 端口可达性——443 端口防火墙放行了吗？
注意：部署后一定要做全链路验证。我曾经见过证书部署成功，但负载均衡器后端还是旧证书——前端握手没问题，后端全挂了。
3. 监控：别等用户告诉你证书过期
监控这件事，说白了就是“别等出事了再补救”。我见过太多公司，证书过期了才知道——还是用户反馈的。
监控应该覆盖这些维度：
| 监控项 | 检查频率 | 告警阈值 |
|---|---|---|
| 证书有效期 | 每天 | 到期前 30 天 |
| 证书链完整性 | 每周 | 链断裂立即告警 |
| 私钥泄露检测 | 实时 | 发现泄露立即吊销 |
| OCSP/CRL 可达性 | 每小时 | 不可达超过 10 分钟 |
你想想看，如果每天自动检查一次，提前 30 天告警，轮换窗口是不是宽裕很多？我习惯用 certbot renew --dry-run 做模拟续期，配合 Prometheus 的 ssl_certificate_expiry 指标，基本不会漏。
4. 到期前预警：黄金 30 天
预警不是发一封邮件就完事了。我建议分三级：
- 一级预警（到期前 30 天）——邮件通知负责人，标记为“计划内轮换”
- 二级预警（到期前 14 天）——邮件 + 即时消息，要求确认轮换时间
- 三级预警（到期前 7 天）——邮件 + 即时消息 + 电话，必须立即处理
关键点：预警系统必须能区分“测试证书”和“生产证书”。测试证书过期无所谓，生产证书过期就是事故。我在项目中就吃过这个亏——测试证书的告警淹没了生产证书的告警。
5. 过期吊销：该放手时就放手
吊销分两种情况：
- 正常过期——证书到期后自动失效，不需要主动吊销
- 紧急吊销——私钥泄露、域名变更、安全事件，需要立即吊销
紧急吊销的流程我建议提前演练。我记得有一次客户私钥泄露，我们花了 2 小时才走完吊销流程——因为找不到 CA 的管理员密码。嗯，从那以后我把所有 CA 的管理凭证都放进了密码管理器，并且每季度验证一次。
避坑指南：吊销后一定要更新 CRL（证书吊销列表）或 OCSP 响应。否则客户端仍然认为证书有效。我曾经见过吊销了证书但 CRL 没更新，攻击者继续用了 3 天。
小结：生命周期管理的关键指标
最后，我整理了一张表格，方便你对照检查自己的流程是否完整：
| 阶段 | 关键动作 | 常见问题 |
|---|---|---|
| 签发 | 生成密钥、提交 CSR、CA 验证 | SAN 遗漏、私钥未加密 |
| 部署 | 安装证书、配置服务、验证链路 | 证书链不完整、权限过大 |
| 监控 | 有效期检查、链完整性、私钥安全 | 监控遗漏、告警阈值不合理 |
| 预警 | 分级通知、确认轮换计划 | 告警淹没、测试/生产不分 |
| 吊销 | 更新 CRL/OCSP、撤销信任 | 吊销后未更新、凭证丢失 |