4、三层CA架构：根CA、策略CA、颁发CA的层级划分
三层CA架构，说白了就是给数字证书世界建一套「中央-省-市」的管理体系。我做了这么多年PKI，见过不少企业一上来就想搞扁平化，结果证书满天飞，谁签的、能干什么、有效期多久，全乱套了。
今天咱们就聊聊这三层到底怎么划，每层该管什么事。
4.1 为什么是三层？不是两层或四层？
你可能会问：两层不够用吗？根CA直接签终端证书，多省事。
嗯，理论上可以。但实际运营中你会发现一个问题：根CA一旦签错一张证书，整个信任链都得重建。我2018年帮一家金融机构做PKI改造时，他们原来的根CA直接签了上千张服务器证书，结果有一张域名校验出错，不得不把所有证书全部吊销——那场面，简直是灾难。
三层架构的核心价值在于：隔离风险，分层管控。
- 根CA：只签下级CA，离线保存，一年用不了几次
- 策略CA：定义证书能干什么、不能干什么，是「立法机构」
- 颁发CA：真正干活儿的，每天签发大量终端证书
四层呢？说实话，除非你的组织架构极其复杂（比如跨国集团+多行业线），否则三层已经够用了。层数越多，验证链越长，性能开销也越大。
核心原则：每一层只做一件事，不做越级操作。
4.2 根CA：整个信任链的「定海神针」
根CA是整个PKI体系的信任锚点。它自签自己的证书，没有上级CA。说白了，你信这个根，才会信它下面签出来的所有证书。
我个人习惯把根CA设计成纯离线。什么意思？就是它的私钥存在一个不联网的硬件安全模块（HSM）里，平时锁在保险柜里。只有需要签发新的策略CA证书时，才拿出来用一次。
| 属性 | 建议值 | 说明 |
|---|---|---|
| 密钥长度 | RSA 4096 或 ECC P-384 | 根CA要用最安全的算法，因为它要撑20年 |
| 有效期 | 15-20年 | 太短了要频繁换根，太长了算法可能过时 |
| 签名策略 | 只签策略CA证书 | 绝不直接签终端证书 |
| 存储方式 | 离线HSM + 物理隔离 | 网络都不接，黑客怎么攻击？ |
我曾经见过一个案例：某公司把根CA的私钥放在一台联网服务器上，结果被勒索软件加密了。虽然私钥有备份，但整个信任链的可信度大打折扣——你永远不知道那段时间私钥有没有被复制过。
4.3 策略CA：证书的「立法者」
策略CA是很多人容易忽略的一层。我刚开始做PKI时也觉得，有根CA和颁发CA不就够了吗？后来发现，没有策略CA，证书的用途边界会变得模糊。
策略CA的核心职责是定义证书策略（Certificate Policy, CP）和认证业务规则（Certification Practice Statement, CPS）。说白了，就是告诉下面的颁发CA：
- 什么类型的用户可以申请什么证书
- 证书的有效期最长多久
- 需要做哪些身份验证
- 吊销条件是什么
举个例子。我帮一家政务云设计CA体系时，策略CA定义了三种策略：
- 策略A：高安全级——用于电子政务外网，要求现场实名认证，有效期1年
- 策略B：中安全级——用于内部办公系统，支持远程视频认证，有效期2年
- 策略C：低安全级——用于测试环境，仅邮件验证，有效期30天
每个颁发CA只能选择其中一种策略来执行。这样，即使某个颁发CA被攻破，损失也被限制在对应的策略范围内。
小技巧：策略CA的证书里会包含一个叫「证书策略扩展」的字段（OID 2.5.29.32）。你可以为每个策略分配一个唯一的OID，这样下游系统就能精确判断一张证书的用途范围。
4.4 颁发CA：真正干活的「执行者」
颁发CA是离用户最近的一层。它负责接收证书请求、验证用户身份、签发终端证书。说白了，用户拿到的每一张证书，都是颁发CA签的。
颁发CA的设计要点有这么几个：
- 在线运营：7×24小时提供服务，所以私钥必须在线，但要做好防护
- 密钥较短：一般用RSA 2048或ECC P-256，够用就行，性能优先
- 有效期短：3-5年，方便轮换
- 按地域或业务拆分：比如华东区一个颁发CA，华南区一个；或者SSL证书一个颁发CA，代码签名一个
我记得有一次，一个客户的颁发CA因为证书请求量暴增，导致响应超时。后来我们做了水平扩展——同一个策略CA下挂多个颁发CA，用负载均衡分发请求。效果立竿见影。
4.5 三层架构的信任模型图
下面这张图展示了一个典型的三层CA信任链。你可以看到，信任是从根CA开始，一路向下传递的。
4.6 各层级证书策略的定义与约束
证书策略（CP）不是写出来就完事了，它必须落实到每一张证书里。我见过不少PKI项目，CP文档写了几十页，但证书扩展字段里啥也没填——那等于白写。
证书策略在X.509 v3证书里通过两个扩展字段体现：
| 扩展字段 | OID | 关键程度 | 说明 |
|---|---|---|---|
| Certificate Policies | 2.5.29.32 | 必须 | 列出该证书遵循的策略OID列表 |
| Policy Mappings | 2.5.29.33 | 可选 | 用于跨CA域的策略映射，三层内一般不用 |
| Policy Constraints | 2.5.29.36 | 建议 | 限制下级CA可以使用的策略范围 |
| Inhibit Any-Policy | 2.5.29.54 | 建议 | 禁止使用「anyPolicy」通配，强制策略匹配 |
举个例子。策略CA签发给颁发CA的证书里，Certificate Policies字段会包含一个OID，比如1.2.3.4.5.1（高安全策略）。同时Policy Constraints会设置requireExplicitPolicy: 0，意思是「下面的证书必须明确声明策略，不准含糊其辞」。
颁发CA签终端证书时，就必须在证书里带上1.2.3.4.5.1这个OID。验证方一看：嗯，策略匹配，信任链没问题。
我曾经踩过一个坑：策略CA签发给颁发CA时，忘了加Policy Constraints扩展。结果颁发CA签出来的终端证书里，策略OID写错了——写成了测试策略的OID。但因为没约束，验证方居然通过了。后来发现时，已经签发了上千张证书，全部得重签。
4.7 层级划分的避坑指南
最后，我把自己这些年踩过的坑总结一下，希望能帮你少走弯路：
- 根CA别图省事放线上——离线保存是底线，别问我为什么知道
- 策略CA的密钥要和根CA分开管理——同一个HSM的不同分区都不行，物理隔离最好
- 颁发CA的数量要适度——不是越多越好，每个颁发CA都需要独立运维，人力和成本都要算
- 证书策略要写进证书，别只写在文档里——文档是给人看的，证书扩展是给机器验证的，两者缺一不可
- 定期审计策略CA的签发记录——策略CA签发的下级CA证书不多，但每一张都很关键，建议每季度审计一次
嗯，三层CA架构的核心就是这些。说白了，就是根CA管信任、策略CA管规则、颁发CA管执行。各司其职，互不越界。这样设计出来的PKI体系，才能既安全又灵活。