4、根证书的生成与管理
根证书是整个证书链的信任锚点。说白了，它就是那个「谁都不信，只信自己」的顶级证书。我见过不少团队在根证书上栽跟头——要么密钥保护不到位，要么生命周期管理一团糟。这一章，咱们就把根证书的生成、保护和管理讲透。
4.1 根密钥的生成与保护
根密钥是PKI体系里最敏感的东西。一旦泄露，整个信任体系就崩塌了。我个人习惯把根密钥的生成分成三步走：
- 选择算法与强度——RSA 4096位或ECDSA P-384是底线
- 安全环境生成——离线、无网络、专用硬件
- 多因子保护存储——密钥分片、硬件加密、物理隔离
核心原则：根密钥永远不应该出现在任何在线系统上。生成时就要假设它会被攻击，所以保护措施必须前置。
4.1.1 密钥生成实操
我推荐使用OpenSSL在离线环境中生成。下面是我在项目中用过的脚本模板：
# 生成RSA 4096位根密钥
openssl genrsa -aes256 -out root-ca-key.pem 4096
# 或生成ECDSA P-384根密钥（我个人更倾向这个）
openssl ecparam -genkey -name secp384r1 -out root-ca-key.pem
# 查看密钥信息
openssl rsa -in root-ca-key.pem -text -noout小技巧：生成时加上 -aes256 参数，密钥文件会被加密。这样即使文件被拷贝，没有密码也打不开。我曾经见过有人裸存私钥文件，结果运维误操作把文件发到了Git仓库……嗯，那场面相当尴尬。
4.1.2 密钥保护方案
密钥保护不是单一措施，而是多层防线。我整理了一个对比表：
| 保护层级 | 措施 | 适用场景 | 我踩过的坑 |
|---|---|---|---|
| 物理层 | 离线存储、保险柜、HSM硬件 | 生产环境根CA | HSM没做双人授权，一个人就能签发 |
| 逻辑层 | 密码加密、密钥分片、访问审计 | 测试/预生产环境 | 分片算法选错，恢复时丢了一片 |
| 流程层 | 多人签名、定期轮换、销毁证明 | 所有环境 | 轮换时忘了更新CRL，旧证书还在生效 |
警告：千万不要把根密钥放在CI/CD流水线里！我见过有团队把根密钥当普通密钥管理，结果Jenkins被攻破，整个CA体系都得重建。那个成本……够买好几辆车的。
4.2 根证书的创建与自签名
根证书是自签名的——它自己证明自己。你想想看，如果根证书还要别人来签，那它就不是根了。创建根证书时，有几个字段特别关键：
- Subject——标识这个CA的身份，要规范命名
- Basic Constraints——必须标记CA:TRUE
- Key Usage——keyCertSign, cRLSign
- Validity Period——通常10-20年，但别太长
4.2.1 自签名证书生成
下面是我常用的配置文件模板：
# root-ca.conf
[ req ]
distinguished_name = req_dn
x509_extensions = v3_ca
prompt = no
[ req_dn ]
CN = My Company Root CA
O = My Company
C = CN
[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:TRUE, pathlen:1
keyUsage = critical, keyCertSign, cRLSign生成命令：
openssl req -x509 -new \
-config root-ca.conf \
-key root-ca-key.pem \
-days 7300 \
-out root-ca-cert.pem注意：pathlen:1 表示这个CA只能签发一级下级CA。我个人建议根CA的pathlen设成0或1，别给太多层级。层级越多，管理复杂度指数级上升。
4.3 根证书的生命周期管理
根证书的生命周期比普通证书长得多，但也不是无限期。我把它分成四个阶段：
- 创建阶段——生成密钥、签发证书、备份
- 运营阶段——签发下级CA、更新CRL、审计
- 轮换阶段——生成新根、交叉签名、迁移
- 销毁阶段——吊销旧根、发布CRL、归档
为什么会需要轮换？因为算法会过时，密钥长度会不够。我记得2015年左右，SHA-1签名算法被彻底攻破，所有用SHA-1的根证书都得换。那次迁移，我们团队整整忙了三个月。
4.3.1 生命周期状态图
下面这张图展示了根证书从生到死的完整流程：
4.3.2 轮换策略要点
根证书轮换是最容易出问题的环节。我曾经在轮换时犯过一个低级错误——新根证书的Subject和旧根一模一样，结果客户端缓存混乱，整整两天服务不可用。后来我总结了几条铁律：
- 交叉签名必须做——新旧根同时存在，让客户端平滑过渡
- 轮换窗口要留足——至少提前6个月发布新根
- CRL要同步更新——旧根吊销后，CRL必须立即生效
- 测试环境先跑一遍——别直接上生产，我吃过这个亏
避坑指南：我曾经在轮换时忘了更新下级CA的证书链。结果新根签发的下级CA证书，客户端验证时找不到信任路径。那次事故让我明白——轮换不只是换根，整个证书链都得跟着更新。
4.4 小结
根证书管理说白了就是三件事：密钥保护好、证书签对、生命周期管住。密钥生成要离线，自签名要加约束，轮换要留窗口。每一步都不能省，每一步都要有审计记录。嗯，这些经验都是真金白银换来的，希望你能少走些弯路。