PKI体系架构：CA、RA、VA的角色与职责，证书策略(CPS)制定
聊到PKI，很多人第一反应就是“发证书的”。其实没那么简单。PKI是一个完整的信任体系，里面有三个核心角色：CA、RA、VA。它们各司其职，缺一不可。我见过不少项目，把RA和VA混为一谈，结果出事了才回头补课。
CA：信任的锚点
CA（证书颁发机构）是整个PKI的根。它负责签发证书、吊销证书、维护证书生命周期。说白了，CA就是那个“盖章的人”。
我个人习惯把CA分成三个层级：
- 根CA（Root CA）：离线部署，私钥锁在硬件安全模块（HSM）里。平时不联网，只在签发下级CA证书时才开机。我见过一个金融客户，根CA的HSM放在保险柜里，双人双锁，每次操作要录像。
- 策略CA（Policy CA）：负责制定证书策略，签发下级CA证书。它受根CA信任，但权限比根CA小。
- 颁发CA（Issuing CA）：真正面向用户和设备发证书的。它在线运行，需要高可用架构。
核心原则：根CA必须离线。这是PKI安全的第一条铁律。我见过有人把根CA挂在公网上，结果被扫到端口，差点出事。
RA：审核与注册
RA（注册机构）是CA的前端。它不直接发证书，而是负责验证申请者的身份。你可以把RA理解成“前台接待”——先核实你是谁，再把申请转给CA。
RA的核心职责包括：
- 接收证书申请
- 验证申请者身份（比如通过AD、LDAP、人工审核）
- 生成密钥对（有些场景下）
- 将审核通过的申请提交给CA
我在项目中遇到过一种情况：某企业把RA和CA部署在同一台服务器上。结果RA被攻破，攻击者直接绕过了审核流程，批量签发了非法证书。嗯，这个教训挺深刻的。
避坑指南：我曾经帮一个客户做安全审计，发现他们的RA日志只保留7天。这根本不够用。证书审核日志至少要保留证书整个生命周期+6个月。否则出了事你根本查不到是谁申请的。
VA：证书状态查询
VA（验证机构）负责回答一个问题：“这个证书现在还有效吗？”它通过OCSP（在线证书状态协议）或CRL（证书吊销列表）提供服务。
VA的设计要点：
- OCSP响应器：实时查询证书状态，延迟要低。我建议用缓存策略，把高频查询的证书状态缓存5-10分钟。
- CRL分发点：定期发布吊销列表。CRL的更新频率很关键——更新太慢，吊销的证书还在用；更新太快，网络开销大。
| 对比项 | OCSP | CRL |
|---|---|---|
| 实时性 | 高（实时查询） | 低（依赖更新周期） |
| 网络开销 | 每次查询都要请求 | 批量下载，一次搞定 |
| 隐私性 | CA知道谁在查哪个证书 | 客户端自己下载，CA不知道 |
| 适用场景 | 高频验证、低延迟要求 | 离线环境、批量验证 |
我的建议：设备证书场景下，优先用OCSP。因为设备数量多、吊销频繁，CRL的更新周期跟不上。但记得给OCSP响应器做负载均衡，否则高并发时容易挂。
证书策略（CPS）制定
CPS（证书实践声明）是PKI的“操作手册”。它详细描述了CA怎么运营、证书怎么发、怎么吊销、怎么审计。CPS不是给用户看的，是给审计员和合规部门看的。
一份完整的CPS应该包含以下内容：
- 概述：CA的名称、适用范围、策略版本
- 证书类型：设备证书、用户证书、代码签名证书等
- 身份验证要求：申请设备证书需要提供哪些信息
- 密钥管理：密钥生成、存储、备份、销毁的流程
- 证书生命周期：签发、续期、吊销、过期处理
- 审计与合规：日志记录、定期审计、事件响应
我写CPS时有个习惯：先画流程图，再写文字。因为流程清楚了，文字才不会乱。下面这张图就是我当时画的核心流程：
CPS制定的实战要点
写CPS不是写论文，是写操作规范。我总结了几条实战经验：
- 别写太虚：CPS里每条策略都要能落地。比如“密钥定期更换”这种话，要写明“每365天更换一次，提前30天触发续期提醒”。
- 考虑异常场景：CA私钥泄露怎么办？HSM故障怎么办？这些都要在CPS里写清楚应急流程。
- 版本管理：CPS要有版本号，每次修改都要记录变更原因。我见过一个客户，CPS三年没更新，结果审计时发现流程早就变了。
特别注意：CPS不是写完了就完事的。它需要定期演练。我建议每半年做一次桌面推演，模拟CA私钥泄露、RA被攻破等场景，看看CPS里的流程能不能跑通。跑不通就赶紧改。
好了，PKI的体系架构和CPS制定就聊到这儿。这三个角色——CA、RA、VA——是PKI的骨架，CPS是血肉。骨架歪了，血肉再丰满也没用。你想想看，如果RA审核形同虚设，CA签发的证书再多，也不过是一堆废纸。