4. 证书生命周期管理：从生到死的完整旅程

证书管理，说白了就是管好一张数字身份证的「一生」。从申请、签发、颁发，到续期、吊销，最后过期处理——每个环节都有坑。我在多个企业的 PKI 项目中都踩过这些坑，今天跟你聊聊我的经验。

4.1 证书申请：第一步就决定了成败

证书申请看起来简单——生成个 CSR 提交上去就行。但我在项目中见过太多因为 CSR 信息填错导致整个 PKI 重来的案例。

申请阶段的核心是 CSR（证书签名请求）。它包含了公钥和身份信息。我个人习惯在生成 CSR 时特别注意以下几点：

• CN（通用名称）：对于服务器证书，CN 必须是完整的域名，比如 api.example.com，不能只写 example.com
• SAN（主题备用名称）：现代浏览器已经不再信任仅依赖 CN 的证书，SAN 才是关键。我建议把所有需要用到的域名都列进去
• 密钥长度：现在至少 2048 位 RSA，我个人推荐 4096 位。ECDSA 的话，P-256 是主流

# 生成私钥和 CSR 的推荐方式
openssl req -new -newkey rsa:4096 -nodes \
  -keyout server.key \
  -out server.csr \
  -config openssl.cnf

4.2 证书签发：CA 的核验与签名

签发是 CA 的工作。收到 CSR 后，CA 需要验证申请者的身份。我记得有一次，一个客户提交的 CSR 里组织名称写错了，CA 直接拒绝了申请——这其实是个好机制。

签发流程大致分三步：

1. 验证 CSR 完整性：检查签名是否有效，公钥是否匹配
2. 身份核验：对于 DV 证书，验证域名控制权；对于 OV/EV 证书，还要验证企业信息
3. 签名并生成证书：CA 用自己的私钥对证书内容签名，生成 X.509 证书

签发过程中，CA 会设置证书的有效期。现在行业趋势是缩短有效期——从以前的 3-5 年，到现在普遍 1 年，甚至 90 天。为什么？

说白了，有效期越长，风险越大。私钥泄露、算法被攻破，这些风险都会随时间增加。我在 Google 的项目里看到他们内部证书有效期只有 30 天，全靠自动化续期来保证可用性。

4.3 证书颁发：安全传输到终端

证书签发完成后，怎么安全地交给申请者？这是个容易被忽视的问题。

常见的颁发方式有：

方式	安全性	适用场景
HTTPS 下载	中等	内部 PKI，网络可控
SCP/SFTP	高	服务器证书批量下发
邮件加密附件	低	不推荐，除非配合 PGP
API 自动获取	高	ACME 协议，推荐方式

我曾经遇到过一个案例：运维人员通过 HTTP 下载证书，结果被中间人攻击替换了证书文件。部署上去后，客户端一直报证书错误，排查了两天才发现问题。从那以后，我坚持所有证书传输必须走加密通道。

4.4 证书续期：别等到最后一刻

续期是证书管理中最容易出问题的环节。你想想看，一个证书过期了，所有依赖它的服务都会中断——HTTPS 网站打不开、mTLS 连接失败、代码签名验证不过。

我建议的续期策略：

• 提前 30 天：开始发送续期提醒
• 提前 7 天：自动触发续期流程
• 提前 1 天：如果还没续期，升级告警级别
• 过期当天：P0 级故障处理

自动化续期现在主流方案是 ACME 协议（Let's Encrypt 用的那个）。我参与过一个项目，用 Certbot 配合 DNS-01 挑战，实现了全自动续期。部署后两年没出过问题——除了有一次 DNS 解析挂了，导致挑战失败。所以，自动化也要有监控和重试机制。

# 使用 certbot 自动续期（推荐）
certbot renew --dry-run  # 先测试
certbot renew            # 实际执行

# 配合 systemd timer 实现定时续期
systemctl enable certbot-renew.timer
systemctl start certbot-renew.timer

4.5 证书吊销：紧急情况下的止损手段

吊销是证书生命周期里最紧急的操作。什么时候需要吊销？

• 私钥泄露（最常见）
• 证书信息变更（比如公司改名）
• 员工离职（针对客户端证书）
• 设备报废

吊销后，CA 会把证书序列号加入 CRL（证书吊销列表） 或通过 OCSP（在线证书状态协议） 提供实时查询。

这里有个坑：CRL 是定期更新的，不是实时的。我记得有一次，客户的私钥泄露了，他们立刻吊销了证书，但 CRL 的下一次更新在 24 小时后。这 24 小时内，攻击者仍然可以用旧证书。后来我建议他们改用 OCSP Stapling，把证书状态的查询频率从天级提升到分钟级。

方案	实时性	性能开销	推荐场景
CRL	低（天级）	低	内部网络，吊销不频繁
OCSP	高（实时）	中	互联网服务，需要快速响应
OCSP Stapling	高（实时）	低（服务端缓存）	高并发场景，推荐

4.6 过期处理：善后工作不能省

证书过期了怎么办？很多人觉得「重新申请一个就行」。但实际情况更复杂。

过期证书的处理流程：

1. 确认服务中断范围：检查哪些服务依赖该证书
2. 紧急签发新证书：走快速通道，跳过部分验证步骤
3. 部署新证书：重启相关服务
4. 验证连通性：确认 mTLS 握手正常
5. 根因分析：为什么自动续期没生效？

另外，过期证书不要立即删除。我习惯保留至少一个完整的证书生命周期（比如 1 年）的归档。为什么？因为有时候需要回溯审计——比如某个客户端在证书过期后发起的连接，日志里需要查证当时用的是哪张证书。

# 检查证书过期时间的命令
openssl x509 -in server.crt -noout -dates

# 批量检查目录下所有证书
for cert in *.crt; do
  echo "$cert: $(openssl x509 -in "$cert" -noout -enddate)"
done

4.7 全生命周期自动化：终极目标

说了这么多，其实核心就一句话：能自动化的，就别手动做。

我参与设计的一个 PKI 平台，实现了以下自动化流程：

• 证书申请：通过内部 CMDB 自动生成 CSR
• 证书签发：对接内部 CA，自动验证和签名
• 证书颁发：通过配置管理工具（Ansible/Puppet）自动部署
• 证书续期：基于 ACME 协议，提前 30 天自动触发
• 证书吊销：检测到私钥泄露事件后，自动吊销并通知所有依赖方
• 过期处理：自动生成审计报告，归档旧证书

这个平台上线后，证书相关的事故从每季度 3-4 起降到了 0。嗯，自动化确实能救命。