3、根CA与中间CA的角色：根CA的信任锚点地位及中间CA的委派作用
说实话，我刚入行时也犯过迷糊：根CA和中间CA，不都是CA吗？有什么区别？直到我亲眼看见一家公司因为根CA私钥被运维误删，不得不撤销所有已签发证书，瘫痪三天——我才真正理解，根CA和中间CA的角色根本不是一个量级。
这一节，我们就来拆开看：根CA为什么是“老大”，中间CA又凭什么“干活”。
3.1 根CA：信任链的“锚点”
根CA证书是自签名的，没有上级。它本身就是信任的起点。浏览器、操作系统里预置的那些根证书，都是这种——它们定义了“谁可以信任”。
我个人习惯把根CA看作种子。种子一旦坏掉，整棵信任树就完了。所以根CA必须离线、冷存储、严格控制访问。我的经验是，根CA主机的网口都能拔掉最好——平时根本不需要联网。
根CA的核心属性：
- 自签名证书，无父级CA
- 生命周期极长（通常20年+）
- 私钥必须离线、硬件加密存储
- 签名极其慎重——一年可能就用几次
- 一旦泄露，整个PKI体系重建
你想想看，如果根CA私钥被偷了，攻击者就可以伪造任何由它签发的证书——不管是中间CA还是终端用户。这可不是闹着玩的。我在项目中见过有人把根CA私钥直接放在运维跳板机上，吓得我当时就建议重做。
3.2 中间CA：承担“脏活累活”
中间CA的角色就是委派。根CA委派给它签发证书的权力，但自己躲在后边。中间CA可以有很多个，每个负责不同的场景：比如一个给内部员工，一个给外部客户，一个给IoT设备。
为什么这么设计？说白了就是隔离风险。万一某个中间CA私钥泄露，我只需要吊销那个中间CA的证书，重新签发一个就行。根CA纹丝不动。
| 对比项 | 根CA | 中间CA |
|---|---|---|
| 签名方式 | 自签名 | 由根CA或上级CA签发 |
| 信任来源 | 自身（信任锚点） | 根CA的委派 |
| 私钥存储 | 离线冷存储，HSM | 在线或离线，HSM可选 |
| 使用频率 | 极低（年/次） | 高（天/次） |
| 泄露影响 | 整个体系崩溃 | 仅影响该分支，可吊销恢复 |
| 生命周期 | 20年+ | 2~5年，可更新 |
我的建议：不要只设一层中间CA。我习惯用两层：策略CA + 签发CA。策略CA定义证书模板和有效期，签发CA负责实际签名。这样策略变更时不用动根，签发CA挂了还能迅速重建。
3.3 委派链的“信任传递”
客户端验证证书时，会沿着证书链向上追溯，直到找到它信任的根证书。整个过程就是信任传递。中间CA证书由根CA签名，终端证书由中间CA签名——每一层都依赖上一层的签名。
我遇到过一种坑：中间CA证书的有效期比根CA短，结果中间CA过期后，所有下级证书都变无效了。嗯，所以中间CA有效期必须覆盖其签发的所有证书的最晚时间。
警告：不要将中间CA的Key Usage随便设置。根CA的Key Usage通常只含keyCertSign和cRLSign。中间CA可以多一个digitalSignature用于OCSP响应签名。乱加会破坏信任链的安全性。
3.4 实战架构：三层模型
我在实际项目中一般采用三层模型：
- 根CA：离线，冷存储，只签发下级CA证书
- 策略CA：在线但低频率，定义证书策略，签发签发CA
- 签发CA：在线高频率，实际签发终端证书
这样可以做到：根CA一年插一次电源就够了，策略CA每周开机一次，签发CA24小时在线。风险最大的签发CA即使被攻破，也只需吊销它并重建，根源不动。
3.5 避坑指南：我踩过的几个坑
- 根CA有效期太短——我见过有人设5年，结果3年后所有中间CA都要跟着换一轮。根CA至少20年。
- 中间CA数量不限——其实每多一个中间CA就多一份密钥管理成本。我建议2~5个就够，按场景分。
- 把根CA主机接入网络——哪怕只是管理口。我曾经在一个项目中，根CA虽然离线，但同事为了方便管理开了SSH，结果被漏洞扫描到。从此我强制根CA只通电源和显示器，网线全拔。
- 中间CA的CRL分发点没配好——客户端验证时找不到CRL，会直接拒绝证书。记得每次签发前检查CDP和AIA字段。
小技巧：写一个脚本，每次生成中间CA证书后自动校验证书链长度和密钥用法。我习惯在CI中加这一步，避免人工检查遗漏。
好了，根CA与中间CA的角色分工就这么简单，但又极其重要。记住：根CA是国家的元首，中间CA是执行部门——元首不能天天批文件，执行部门也不能拥有核按钮。下一章我们会深入密钥生成的具体操作。