4. 根证书管理：根证书的生成、自签名、安全存储（HSM）、生命周期管理

根证书是整个PKI体系的信任锚点。说白了，它就是那个“我信它，所以它签发的证书我都信”的终极源头。我见过不少团队在根证书管理上栽跟头，要么是私钥保护不到位，要么是生命周期一团乱麻。这一章，咱们就把根证书从生到死的每个环节掰开揉碎讲清楚。

4.1 根证书的生成与自签名

根证书和普通证书最大的区别在于：它是自签名的。也就是说，它的签发者和使用者是同一个实体。没有上级CA给它背书，它自己就是自己的权威来源。

生成根证书时，有几个关键参数必须慎重选择：

• 密钥算法：我个人习惯用RSA 4096位或ECDSA P-384。2048位虽然还合规，但考虑到根证书通常要服役10-20年，还是留足余量比较好。
• 签名哈希算法：至少SHA-256，千万别再用SHA-1了。我在2017年还见过一个客户的根证书用SHA-1签名，当时就建议他们立刻轮换。
• 有效期：根证书的有效期通常很长，10年、15年甚至20年都很常见。但越长越要小心，因为一旦私钥泄露，整个信任体系都得重建。
• Basic Constraints：必须标记为CA:TRUE，Path Length可以设为0或1。设为0意味着它只能签发终端实体证书，不能签发下级CA。

下面是一个使用OpenSSL生成自签名根证书的典型过程：

# 生成根CA私钥（RSA 4096位）
openssl genrsa -out root-ca.key 4096

# 生成自签名根证书（有效期15年）
openssl req -x509 -new -nodes \
  -key root-ca.key \
  -sha256 -days 5475 \
  -out root-ca.crt \
  -subj "/C=CN/ST=Beijing/L=Beijing/O=MyOrg/CN=MyOrg Root CA 2025" \
  -extensions v3_ca

4.2 根证书私钥的安全存储（HSM）

根证书的私钥是整个PKI体系里最敏感的数据。一旦泄露，攻击者就能冒充你的CA签发任意证书。所以，私钥绝对不能放在普通服务器的文件系统里——哪怕加密了也不行。

业界标准做法是使用硬件安全模块（HSM）。HSM是一种专用的硬件设备，专门用来生成、存储和使用加密密钥。它的核心特点是：私钥一旦生成，就永远无法以明文形式导出。

HSM的几个关键能力：

• 密钥生成在内部完成：私钥在HSM内部生成，从不离开设备。
• 签名操作在内部完成：需要签名时，把待签名的数据送进HSM，它在内部用私钥签名，然后把签名结果送出来。私钥全程不暴露。
• 防篡改和防物理攻击：HSM有物理防护机制，一旦检测到有人试图拆解，会自动擦除所有密钥。
• 多因素访问控制：通常需要多张管理员卡和对应的PIN码才能激活HSM。

用HSM生成根证书私钥的流程大致如下：

# 在HSM内部生成RSA 4096密钥对（以Thales Luna为例）
hsm login -partition MyPartition -password ****
hsm generatekey -algorithm RSA -size 4096 -label "RootCA Key" -capability sign

# 使用HSM中的私钥生成自签名证书
openssl req -x509 -new \
  -engine pkcs11 -keyform engine \
  -key "pkcs11:token=MyPartition;object=RootCA%20Key;type=private" \
  -sha256 -days 5475 \
  -out root-ca.crt \
  -subj "/C=CN/ST=Beijing/L=Beijing/O=MyOrg/CN=MyOrg Root CA 2025"

4.3 根证书的生命周期管理

根证书的生命周期管理，说白了就是回答三个问题：什么时候发？什么时候换？什么时候废？

我习惯把根证书的生命周期分为四个阶段：

4.3.1 颁发

根证书的颁发不是简单的“生成一个证书就完事”。它需要配套的治理流程：谁有权发起？谁有权审批？生成过程需要几个人同时在场？

我建议至少遵循以下步骤：

1. 制定证书策略（CP）和认证业务声明（CPS）：明确根证书的用途、管理规则和法律责任。
2. 准备HSM和访问控制：确保HSM已初始化，管理员卡和PIN已分发给至少两名管理员。
3. 在HSM中生成密钥对：至少两名管理员同时在场，分别插入各自的管理员卡并输入PIN。
4. 生成自签名证书：使用HSM中的私钥生成证书，并打印出证书指纹进行人工核对。
5. 备份根证书和HSM配置：根证书（公钥部分）可以公开分发；HSM的配置和密钥备份要妥善保管。

4.3.2 轮换

根证书轮换是PKI运维里最考验功力的操作。为什么？因为根证书一旦换了，所有信任它的客户端都得更新信任存储。这个过程可能持续数月甚至数年。

轮换的核心策略是新旧共存：

• 提前生成新的根证书，但先不撤销旧的。
• 用新根证书签发新的下级CA证书，同时旧根证书继续为已有的下级CA背书。
• 给客户端足够的时间去信任新根证书。
• 等所有依赖旧根证书的证书都到期或轮换后，再安全停用旧根证书。

4.3.3 撤销

根证书撤销是最后的手段。一旦撤销，所有由该根证书签发的下级CA和终端证书都会失效。这相当于推倒了整座信任大厦。

什么情况下必须撤销根证书？

• 私钥泄露：这是最严重的情况。一旦确认私钥泄露，必须立即撤销根证书，并通知所有依赖方。
• CA运营终止：如果整个CA体系要关闭，根证书也需要撤销。
• 发现严重算法缺陷：比如根证书用的哈希算法被发现存在碰撞风险。

撤销根证书的方式通常是通过证书撤销列表（CRL）或在线证书状态协议（OCSP）。但要注意，根证书本身通常没有上级CA来签发它的CRL，所以根证书的撤销信息一般通过带外渠道发布，比如CA的官方公告、浏览器厂商的信任存储更新等。

4.4 根证书管理的核心流程

下面这张图总结了根证书从生成到退役的完整生命周期：

4.5 根证书管理的几个关键原则

最后，我想分享几条我在实践中总结出来的原则：

• 根证书私钥必须离线存储：只在需要签发下级CA证书时才临时接入HSM，平时物理断开网络。
• 多人控制：至少需要两人同时在场才能操作根证书私钥。这是防止单点作恶的基本手段。
• 定期审计：每年至少审计一次根证书的使用情况、HSM的访问日志和密钥备份的完整性。
• 提前规划轮换：不要等到根证书快过期了才想轮换的事。提前两三年规划，给客户端留足迁移时间。
• 文档化一切：根证书的生成过程、HSM配置、管理员名单、轮换计划，全部写成文档。你想想看，万一负责人生病了，新人接手时两眼一抹黑，那可就麻烦了。