4. CA体系架构：根CA与中间CA、证书链构建、交叉认证、CA的层级设计原则

这一章我们聊聊CA的体系架构。说白了，就是CA该怎么搭、怎么分层、怎么让证书链走得通。

我见过不少团队，一开始图省事，直接拿根CA签所有证书。结果呢？根CA私钥一旦泄露，整个信任体系全崩。嗯，这其实是个很典型的坑。

4.1 根CA与中间CA：为什么不能只有一层？

先看一个最基础的问题：为什么要有根CA和中间CA？

根CA是整个信任链的锚点。它的私钥一旦生成，就应该被锁进保险柜——物理隔离、离线存储、甚至用HSM硬件保护。我习惯把根CA的私钥比作「核按钮」，平时绝对不能碰。

中间CA则负责实际签发证书。它从根CA那里拿到授权，然后给终端设备、服务器、用户发证书。这样设计的好处很明显：

• 风险隔离：中间CA私钥泄露，只需要吊销它的证书，重新签发一个。根CA纹丝不动。
• 灵活扩展：可以按业务线、地域、安全等级创建多个中间CA，各自独立运营。
• 审计清晰：每一张证书都能追溯到签发它的中间CA，再追溯到根CA。

我在一个金融项目里遇到过，客户坚持用根CA直接签服务器证书，理由是「省事」。结果半年后根CA私钥被运维人员误操作导出，整个PKI重建。那叫一个惨。

4.2 证书链构建：从终端到根

证书链，就是一张证书从终端设备一路追溯到根CA的路径。浏览器或操作系统验证证书时，会沿着这条链逐级检查签名。

举个例子，一张设备证书的链可能是这样的：

设备证书（Leaf）
  └─ 由中间CA1签发
中间CA1证书
  └─ 由根CA签发
根CA证书（自签名）

验证流程其实不复杂：

1. 拿到设备证书，提取签发者信息，找到中间CA1证书。
2. 用中间CA1的公钥验证设备证书的签名。
3. 提取中间CA1的签发者信息，找到根CA证书。
4. 用根CA的公钥验证中间CA1的签名。
5. 根CA是自签名，用自身公钥验证自身签名。

这里有个细节：证书链的构建顺序。我建议在TLS握手时，服务器把完整的证书链（设备证书+中间CA证书）一起发给客户端。为什么？因为客户端不一定能自动补全中间证书。我曾经排查过一个线上故障，就是因为服务器只发了设备证书，客户端找不到中间CA，验证失败。

4.3 交叉认证：让不同PKI体系握手

交叉认证，说白了就是让两个独立的PKI体系互相认可。比如公司A收购了公司B，两家都有自己的根CA。怎么让A的设备信任B签发的证书？

两种常见做法：

• 单向交叉认证：A的根CA给B的根CA签一张交叉证书。A的设备信任A的根CA，A的根CA信任B的根CA，所以A的设备也信任B签发的证书。
• 双向交叉认证：两边互相签交叉证书，实现双向信任。

交叉认证的证书链会变长。举个例子：

B签发的设备证书
  └─ 由B的根CA签发
B的根CA证书
  └─ 由A的根CA签发的交叉证书
A的根CA证书（自签名）

我记得有一次帮客户做跨国PKI整合，两边根CA的算法还不一样——一边用RSA 2048，一边用ECC P-256。交叉认证时，签名算法必须兼容。最后我们做了个中间CA桥接，才把两条链串起来。

4.4 CA的层级设计原则

CA层级怎么设计？我总结了几条经验：

原则	说明	我的建议
最少层级	层级越少，验证路径越短，性能越好	2~3层（根CA + 1~2层中间CA）
职责分离	不同安全等级的证书用不同中间CA签发	设备证书、用户证书、代码签名证书分开
地域隔离	跨国部署时，每个区域独立中间CA	避免跨洲证书链延迟
算法演进	根CA用长密钥（如RSA 4096），中间CA用短密钥	方便未来算法升级
吊销可控	每个中间CA独立维护CRL/OCSP	吊销一个中间CA不影响其他

你想想看，如果所有证书都走同一个中间CA，一旦这个CA需要升级算法，所有证书都得重新签发。分开之后，按业务线逐步迁移，风险小得多。

4.5 一张图看懂CA层级架构

下面这张图展示了一个典型的3层CA架构。根CA离线存储，只签发两个中间CA。中间CA1负责设备证书，中间CA2负责用户证书。每个中间CA下面挂着具体的终端实体。

这张图里，根CA只做一件事——签发中间CA。中间CA再各自负责自己的领域。这样设计，即使中间CA1的私钥泄露，也只需要吊销它，重新签发一个，根CA和中间CA2完全不受影响。

好了，这一章的内容就到这里。CA架构设计没有标准答案，但「根CA离线、中间CA按需拆分、证书链尽量短」这三条，基本不会错。