4. 证书颁发机构(CA)：功能、类型与部署模式

CA，全称 Certificate Authority，也就是证书颁发机构。

说白了，它就是 PKI 体系里那个负责发“身份证”的权威机构。没有它，数字证书就是一纸空文。我见过不少团队，为了省事随便搭个 CA 就上线，结果后续的证书管理和信任问题搞得一塌糊涂。

这章咱们就把它掰开揉碎了讲清楚。

4.1 CA 的核心功能

一个合格的 CA，至少要干这几件事。相信我，少一个都不行。

• 证书签发：验证申请者身份后，生成并签署数字证书。这是它最基础的活。
• 证书撤销：当私钥泄露或人员离职时，CA 必须能把那张证书拉进黑名单。这就是 CRL 或 OCSP 的作用。
• 证书续期：证书有有效期，快到期的证书需要 CA 重新签发。我建议自动化完成，手动续期容易出事故。
• 密钥生命周期管理：包括 CA 自身密钥的生成、存储、备份和销毁。这部分最容易被忽视，但也最重要。
• 发布状态信息：通过 CRL 或 OCSP 响应器，向所有人公开证书当前的有效状态。
• 审计与日志：所有操作必须有日志，出了问题才好追责。嗯，合规要求往往也卡在这里。

4.2 CA 的类型

你想想看，现实中的“权威机构”也有不同级别。CA 也是一样，主要分为三类。

类型	信任范围	典型场景
公共 CA	全球、互联网	HTTPS 网站、电子邮件签名
私有 CA	企业内部组织	内部 VPN、代码签名、Wi-Fi 认证
第三方托管 CA	特定联盟或行业	车联网 V2X、特定供应链认证

公共 CA 的根证书预装在浏览器和操作系统里。它们受严格的行业规范约束，比如 WebTrust 审计。私有 CA 则完全由你掌控，部署灵活，但需要自己维护信任列表。

我个人的经验是：能用公共 CA 的场景，尽量别自己搭。自己维护一套 CA 基础设施，成本远比想象的高。

4.3 CA 的部署模式

模型选好了，接下来就是怎么摆的问题。CA 的部署模式决定了你的信任边界和容灾能力。

4.3.1 单层 CA

就一个 CA，自己给自己签名。根证书同时也是签发证书。

• 优点：简单，部署快。适合测试或小型环境。
• 缺点：一旦根私钥泄露，全军覆没。而且根证书离线保护不方便。

4.3.2 双层 CA

这是生产环境中最常见的做法。分为根 CA 和中间 CA。

• 根 CA：离线保存，物理隔离。专门给中间 CA 签名。
• 中间 CA：在线运行，负责给最终用户签发证书。

4.3.3 跨信任域层级

当多个组织需要互信时，可以采用桥 CA 或交叉认证。

• 桥 CA：作为中间桥梁，连接两个不同的 PKI 体系。
• 交叉认证：两个 CA 互相为对方的根证书签名，建立双向信任。

这种模式在并购整合或联盟合作中很常见。我建议先梳理清楚双方的证书策略，再动工，否则后期策略冲突会让你修到怀疑人生。

4.4 CA 的信任边界与物理安全

部署模式直接决定了信任边界。举个例子：

单层 CA 信任边界：
[在线 CA] --- 直接签发 ---> [终端实体证书]

双层 CA 信任边界：
[离线根 CA] --- 签发 ---> [在线中间 CA] --- 签发 ---> [终端实体证书]

双层模式下，即使中间 CA 被攻破，只要根 CA 还在，你就能吊销中间 CA 的证书，重建信任。这就是“分层防护”的精髓。

4.5 实战部署建议

说了这么多，最后给几个我自己的经验总结吧。

1. 用双层架构：除非你只是搭来玩玩，否则永远用双层。根 CA 离线放在保险柜里最安全。
2. 硬件安全模块：有条件的话，CA 私钥一定要存在 HSM 里。软件密钥在服务器上就是裸奔。
3. 定期演练：我曾经见过一个公司，CA 崩了之后才发现备份根本恢复不了。CA 的恢复流程必须定期演练，不能当摆设。
4. 日志不可篡改：CA 的操作日志要写入独立的日志服务器，最好用区块链或 WORM 存储，保证事后审计的完整性。
5. 关注证书透明度：现在 Chrome 和 Safari 都要求公共 CA 的证书必须上报到 CT 日志。如果你的 CA 不兼容 CT，浏览器会报错。