4. 证书颁发机构(CA)
说到PKI，大家第一个想到的往往是证书。但证书谁发的？就是CA——证书颁发机构。说白了，CA就是PKI体系里的“身份登记处”兼“印章管理局”。
很多刚入门的朋友觉得CA不就是个发证软件嘛，装一个跑起来就行了。嗯，我一开始也是这么想的，直到在实际项目中吃过亏才发现——CA的角色设计和层次划分，直接决定了整个PKI体系的安全边界。
今天我们就来把CA这层皮彻底扒开，看看它到底扮演什么角色，根CA和子CA又是怎么分工的。
4.1 CA的基本角色和职责
CA在PKI中的核心职责，我总结为三个词：核身、签发、管理。但这三个词背后的事可不简单。
- 身份验证（核身）：申请者是不是他声称的那个人/设备/系统？验证强度决定了证书的信任等级。
- 证书签发：用CA自己的私钥对申请者的公钥和身份信息做数字签名，生成证书。
- 生命周期管理：证书下发后，CA还得负责吊销、更新、冻结、归档。
我个人习惯把CA理解成“信任锚点”。整个PKI系统里，所有参与者信任的不是某个具体的证书，而是信任那个签发证书的CA。如果CA不可信了，它签的所有证书瞬间变废纸。
核心原则：CA的私钥是整个信任链的命根子。私钥泄露=信任崩塌。
我在项目中遇到过一种情况：某个客户把CA服务器直接放在公网上跑，连HSM（硬件安全模块）都没用，私钥以文件形式存在硬盘里。我当时就冷汗下来了——这相当于把保险柜钥匙挂在门口。
4.2 根CA与子CA的职责分离
理论上，你可以只用一台CA签发所有证书。但真正生产环境没人这么干。为什么？风险太集中了。
于是就有了分层设计：根CA（Root CA） 和 子CA（Subordinate CA），有时也叫中间CA（Intermediate CA）。
| 对比维度 | 根CA | 子CA |
|---|---|---|
| 定位 | 信任原点，自签名证书 | 由根CA签发，向下服务 |
| 私钥暴露风险 | 极高，必须离线/物理隔离 | 中等，可在线运行但需保护 |
| 运营频度 | 极低，一年用几次 | 高，日常签发业务证书 |
| 证书用途 | 仅签发子CA | 签发最终实体证书（服务器/用户/设备） |
| 吊销影响 | 整个信任链失效 | 仅影响该子CA签发的证书 |
你想想看，根CA就好比国家印章。平时锁在保险柜里，只有颁发“子机构授权书”时才拿出来按一下。而子CA就是各地的办事处印章，日常事务用它来办。
为什么会这么设计？职责分离 + 风险隔离。
- 根CA的私钥一旦泄露，整个PKI体系需要重建——所有子CA证书要重新签发，所有终端证书要重新下发。这是灾难级的。
- 子CA的私钥泄露，影响范围被限制在它管辖的证书集合内。根CA发个CRL（证书吊销列表）吊销这个子CA证书就行，其他子CA不受影响。
我记得有一次做金融客户的PKI方案，对方坚持只用一层CA架构，觉得两层太麻烦。我问他：“你这个CA私钥如果被运维人员带走，你们所有网银证书怎么办？”他沉默了。最后老老实实改成了根CA离线+子CA在线的两级架构。
实践建议：
- 根CA的私钥生成必须在离线环境完成，最好用HSM或智能卡存储。
- 根CA的签发操作需要至少两人共同参与（密钥仪式）。
- 子CA可以部署在在线环境中，但私钥仍建议HSM保护。
4.3 子CA的扩展场景与密钥边界设计
子CA不一定只有一个。大型企业或CA运营商会构建多级子CA体系。这背后是对“密钥边界”的精细控制。
什么叫密钥边界？一个私钥能触及的安全域。根CA的密钥边界是整个PKI，子CA的密钥边界是它负责的那一块。
常见的子CA划分方式：
- 按组织边界划分：不同部门、不同子公司各有一个子CA。比如财务部一个子CA，研发部一个子CA。即使研发子CA出问题，财务的证书不受影响。
- 按证书类型划分：SSL/TLS服务器证书一个子CA，代码签名证书一个子CA，个人用户证书一个子CA。每种证书的策略、验证强度、生命周期都不同。
- 按信任等级划分：高安全等级（如核心交易系统）用一级子CA签发的证书，普通等级用二级子CA签发的证书。
- 按地理区域划分：跨国企业不同国家的合规要求不同，每个区域独立子CA。
避坑指南：子CA证书的路径长度约束（pathLenConstraint）一定要设置好。我曾经见过一个案例，因为没设置约束，导致有人用子CA再签发子CA，信任链无限延伸，最后证书路径验证时性能崩溃。
关于子CA的证书扩展项，有几个关键字段我建议你重点关注：
| 扩展项 | 含义 | 推荐设置 |
|---|---|---|
BasicConstraints |
标记是否为CA，以及路径长度 | 子CA必须设为CA:TRUE，路径长度>=0 |
KeyUsage |
密钥用途 | 根CA通常只保留keyCertSign和cRLSign |
ExtendedKeyUsage |
扩展密钥用途（仅在叶证书使用） | 子CA一般不设置，让下级叶证书自己约束 |
NameConstraints |
限定子CA只能签发特定名称空间的证书 | 建议企业级PKI使用，控制边界 |
4.4 一张图看懂根CA与子CA的关系
下面这张SVG图，我故意把它画得非常直观。你一看就明白这种层次结构是怎么运作的。
4.5 不同信任模型下的CA角色
CA的角色不是一成不变的，它取决于你采用哪种信任模型。我简单列三种主流模型，方便你对比：
| 信任模型 | CA角色特点 | 典型场景 |
|---|---|---|
| 严格层次模型 | 根CA唯一，子CA严格继承 | 大型企业、政府PKI |
| 网状模型 | 多个CA互相交叉认证，没有根 | 联盟式信任（如桥CA） |
| 信任列表模型 | 客户端本地维护受信CA列表 | 浏览器HTTPS信任 |
我个人最推荐的是严格层次模型。虽然部署起来麻烦一些，但信任路径清晰，吊销管理方便，出了问题也容易追溯。网状模型我调试过几次，路径建立和验证逻辑简直是一场噩梦。