2、证书生命周期管理：证书签发、部署、监控、轮换、吊销全流程

证书管理，说白了就是管好一张数字身份证的「生老病死」。很多团队只关注怎么签发证书，却忽略了后面的监控和轮换。我见过不少线上事故，都是因为证书过期没人管，服务突然就挂了。

这一章，我把整个生命周期拆成五个阶段来讲。每个阶段都有我踩过的坑，希望能帮你少走弯路。

2.1 证书签发：从 CSR 到签名

签发是起点。我个人习惯把签发流程分成三步：生成密钥对、构造 CSR、提交 CA 签名。每一步都有讲究。

2.1.1 密钥生成

密钥是证书的根基。我建议用 RSA 4096 位或 ECDSA P-384。为什么？RSA 2048 虽然还安全，但很多合规要求已经明确要 4096 了。ECDSA 性能更好，但兼容性稍差——你想想看，有些老设备只认 RSA。

# 生成 RSA 4096 位私钥
openssl genrsa -out server.key 4096

# 生成 ECDSA P-384 私钥
openssl ecparam -genkey -name secp384r1 -out server.key

2.1.2 CSR 构造

CSR 里最关键的是 Common Name (CN) 和 Subject Alternative Names (SANs)。现在浏览器已经不认 CN 了，全靠 SAN。所以 SAN 必须写全，一个域名都不能漏。

openssl req -new -key server.key -out server.csr \
  -subj "/C=CN/ST=Beijing/L=Beijing/O=MyCompany/CN=api.example.com" \
  -addext "subjectAltName=DNS:api.example.com,DNS:www.example.com"

2.1.3 CA 签署策略

内部 CA 还是公共 CA？我建议分场景：

场景	推荐方式	有效期
内部服务间通信	内部 CA (如 cfssl / step-ca)	1 年
面向用户 Web 服务	公共 CA (Let's Encrypt / 商业 CA)	90 天
设备证书 / IoT	内部 CA + 短有效期	30 天

2.2 证书部署：别让配置成为瓶颈

部署看起来简单，就是把证书文件和私钥放到正确的位置。但实际项目中，我遇到过太多「配置写死」导致轮换困难的情况。

2.2.1 部署路径规范

我建议统一证书存放路径，方便脚本管理：

/etc/ssl/certs/    # 证书文件
/etc/ssl/private/  # 私钥文件 (权限 600)
/etc/ssl/ca/       # CA 证书链

2.2.2 热加载支持

Nginx、Envoy、HAProxy 都支持证书热加载。但有个坑：有些版本需要发送 SIGHUP 信号，有些则自动检测文件变化。我建议统一用 API 触发重载，而不是依赖文件监控。

# Nginx 热加载证书
nginx -s reload

# Envoy 通过 admin 接口
curl -X POST http://127.0.0.1:9901/logging?level=info

2.3 证书监控：提前发现，别等报警

监控是生命周期的「眼睛」。我见过太多团队等到证书过期才收到报警，然后手忙脚乱地轮换。其实完全可以提前预警。

2.3.1 监控指标

• 剩余有效期：低于 30 天触发警告，低于 7 天触发严重
• 证书链完整性：中间证书是否缺失
• 私钥匹配：证书与私钥是否配对
• 吊销状态：OCSP 响应是否正常

2.3.2 监控工具选型

工具	适用场景	部署方式
Prometheus + blackbox_exporter	外部 HTTPS 端点监控	Kubernetes / 裸机
Cert-manager (K8s)	Kubernetes 集群内证书	Operator 模式
OpenSSL 脚本 + CronJob	传统服务器	定时任务

# 用 OpenSSL 检查证书有效期
openssl x509 -in /etc/ssl/certs/server.crt -noout -enddate

# 检查证书链
openssl verify -CAfile /etc/ssl/ca/ca.crt /etc/ssl/certs/server.crt

2.4 证书轮换：平滑替换的艺术

轮换是核心操作。说白了，就是在旧证书过期前，用新证书无缝替换掉它。我总结了一套「三步轮换法」。

2.4.1 轮换策略

• 提前轮换：在过期前 7-14 天执行，留足回滚时间
• 灰度发布：先替换少量实例，观察 24 小时再全量
• 自动回滚：如果新证书有问题，自动切回旧证书

2.4.2 轮换脚本示例

#!/bin/bash
# 证书轮换脚本 - 适用于 Nginx

CERT_DIR="/etc/ssl/certs"
KEY_DIR="/etc/ssl/private"
BACKUP_DIR="/etc/ssl/backup/$(date +%Y%m%d%H%M%S)"

# 1. 备份旧证书
mkdir -p $BACKUP_DIR
cp $CERT_DIR/server.crt $BACKUP_DIR/
cp $KEY_DIR/server.key $BACKUP_DIR/

# 2. 部署新证书
cp new_server.crt $CERT_DIR/server.crt
cp new_server.key $KEY_DIR/server.key
chmod 600 $KEY_DIR/server.key

# 3. 验证新证书
openssl verify -CAfile /etc/ssl/ca/ca.crt $CERT_DIR/server.crt
if [ $? -ne 0 ]; then
  echo "证书验证失败，触发回滚"
  cp $BACKUP_DIR/server.crt $CERT_DIR/server.crt
  cp $BACKUP_DIR/server.key $KEY_DIR/server.key
  exit 1
fi

# 4. 热加载
nginx -s reload
echo "轮换完成"

2.5 证书吊销：最后的防线

吊销是很多人忽略的环节。说实话，大部分团队只在私钥泄露时才想起吊销。但吊销机制本身需要提前规划。

2.5.1 吊销方式对比

方式	原理	实时性	适用场景
CRL (证书吊销列表)	CA 定期发布黑名单	低 (小时级)	内部网络，可接受延迟
OCSP (在线证书状态协议)	实时查询证书状态	高 (秒级)	面向用户的服务
OCSP Stapling	服务端缓存 OCSP 响应	高 (秒级)	高性能场景

2.5.2 吊销触发条件

• 私钥泄露：立即吊销，生成新密钥对
• 域名变更：旧证书不再需要
• 员工离职：撤销其持有的客户端证书
• 合规要求：定期吊销并重新签发

# 使用 cfssl 吊销证书
cfssl revoke --serial=1234567890abcdef --ca=ca.pem --ca-key=ca-key.pem

# 生成 CRL
openssl ca -gencrl -out crl.pem -config openssl.cnf

2.6 自动化：让生命周期自己转起来

手动管理证书生命周期，在几十个节点时还能应付。一旦规模上千，就必须自动化。我个人推荐用 cert-manager + Let's Encrypt 的组合，配合 ACME 协议实现全自动签发和轮换。

但自动化不是银弹。你想想看，如果自动轮换脚本本身出错了怎么办？所以自动化系统也要有「人工介入」的接口——比如手动触发轮换、手动回滚、手动吊销。