2、证书颁发机构(CA)的角色与功能：根CA、中间CA、交叉认证
说到 PKI，CA 就是整个信任链的源头。我个人习惯把 CA 看成“数字世界的公证处”——它负责签发、管理和吊销证书。但你仔细看，CA 不是只有一种。根 CA、中间 CA、交叉认证，这三个概念搞不清楚，后面做上线验证的时候一定会踩坑。
根CA —— 信任链的“祖宗”
根 CA 是整个证书链的起点，它的证书是自己签自己的（自签名证书）。也就是说，根 CA 不需要别人来证明它可信，因为它就是最高层。我记得刚入行时有个项目，客户直接把根 CA 服务器挂在生产网上，每天对外签发证书……后果？私钥泄露风险极大。后来我建议他们：根 CA 必须离线存储，只在需要签发中间 CA 证书时才通电。
根 CA 一般有这几个特性：
- 自签名证书 —— 没有上级 CA 背书
- 长期有效 —— 通常 10–20 年，换了根证书所有下级都得重新签发
- 离线操作 —— 签发完成后就断网、锁柜子
- 严格审计 —— 每一次私钥使用都要有记录
中间CA —— 真正干活的“打工人”
根 CA 不能天天出来签发终端证书，那样风险太高。所以我们在根 CA 下面挂一个或几个中间 CA。中间 CA 的证书由根 CA 签发，然后中间 CA 再去给 Web 服务器、VPN 设备、用户客户端等发证书。
你想想看，为什么要有中间 CA？说白了就是分层隔离。万一某台中间 CA 被攻破，我们只需要吊销它的证书，然后重新签发一个新的中间 CA 就行。根 CA 的私钥不用动，整个信任体系不会崩塌。我在一次企业 PKI 改造中就遇到过类似情况：一个部门的中间 CA 私钥管理的日志丢了，我们直接吊销了那台中间 CA，所有用户证书重新通过新的中间 CA 签发，根 CA 纹丝不动。
根CA vs 中间CA —— 一张表说清楚
| 特性 | 根CA | 中间CA |
|---|---|---|
| 证书来源 | 自签名 | 由根CA签发 |
| 有效期限 | 10–20年 | 2–5年（常与业务周期匹配） |
| 私钥使用频率 | 极低（仅签发中间CA） | 中等（签发终端证书/CRL） |
| 安全等级要求 | 物理隔离 + 加密机 | 软件加密或HSM，可在线 |
| 被攻破后果 | 整个PKI瓦解 | 仅影响该中间CA下的证书 |
交叉认证 —— 让不同PKI“握手”
嗯，交叉认证这个概念很多人觉得复杂。说白了就是一个组织信任另一个组织的 CA 证书。比如公司 A 收购了公司 B，两个公司原本各有一套 PKI。想让 A 的员工证书被 B 的服务器信任？有两种做法：要么重建一套统一 PKI（成本高），要么做交叉认证。
交叉认证又分两种：
- 单向交叉认证 —— A 的根 CA 签发一个证书给 B 的根 CA，这样 A 信任 B 的证书链，但 B 不一定信任 A。
- 双向交叉认证 —— 两边互相签发交叉证书，彼此信任。
我去年帮一个金融集团做 PKI 合并，他们就是用了双向交叉认证。注意一个细节：交叉证书也需要定期更新和吊销，否则旧的证书链会引发信任断裂。我曾经在测试环境中忘记配置交叉证书的 CRL 分发点，结果所有依赖交叉认证的服务都验证失败，排查了大半天才找到原因。
openssl verify 命令加 -CAfile 参数，逐个检查证书路径是否完整。
证书链与交叉认证示意图
下面这张图帮你理清根 CA、中间 CA 和交叉认证之间的关系。我每次做 PKI 规划时都会先画类似的结构图，避免后续配置出错。
上线验证前必须确认的几件事
不管你是建新的 PKI，还是做交叉认证，上线前我建议逐一核对这个清单：
- 证书链完整性 —— 客户端能否找到根证书？中间 CA 的证书是否包含在链里？
- CRL 和 OCSP 可达 —— 吊销状态查询地址有没有配错？防火墙放行没？
- 交叉证书有效期 —— 两边根 CA 的交叉证书过期时间是否覆盖了业务证书生命周期？
- 密钥用法 (Key Usage) —— 中间 CA 是否允许签发（keyCertSign）？交叉证书是否带上
basicConstraints: pathLenConstraint？
openssl s_client -connect yourserver:443 -showcerts 查看实际交付的证书链，然后手动用 openssl verify -CAfile <根证书> -untrusted <中间证书> <终端证书> 验证。我每次上线前都会跑一遍这条命令，胜过看十遍理档。
最后说一句心里话：CA 的角色设计，本质上就是“信任的分配”。根 CA 是信任的锚点，中间 CA 是信任的分发渠道，交叉认证是信任的桥梁。把这三者搞清晰，你的 PKI 架构就能少一半的运维事故。