3、传统PKI架构：CA、RA、VA的角色与职责，证书签发流程，CRL与OCSP吊销机制，PKI在IoT中的局限性
聊到PKI，很多人第一反应就是“证书”。其实PKI是一整套基础设施，不是单个软件。我最早接触PKI是在做金融加密机的时候，那时候觉得这东西太“重”了，一个证书签发流程要走好几道手续。后来做IoT，才发现传统PKI在资源受限设备上，简直是“大象踩蚂蚁”。
这一章，我们先把传统PKI的骨架拆开看。CA、RA、VA分别干什么，证书怎么签发的，吊销怎么做的。最后，我会结合IoT场景，说说为什么传统PKI“水土不服”。
3.1 核心角色：CA、RA、VA
传统PKI有三个核心角色，我习惯把它们比作“发证机关”、“初审窗口”和“查询台”。
| 角色 | 全称 | 核心职责 | 我见过的坑 |
|---|---|---|---|
| CA | Certificate Authority | 签发、吊销证书，维护证书生命周期 | CA私钥泄露，整个信任链崩塌 |
| RA | Registration Authority | 身份审核、资料校验，不直接签发证书 | RA被绕过，CA直接接收伪造请求 |
| VA | Validation Authority | 提供证书状态查询（CRL/OCSP） | VA响应慢，设备端超时直接放行 |
关键点：CA是信任锚点，RA是安全边界，VA是实时状态窗口。三者缺一不可，但IoT场景下，RA和VA往往被“阉割”了。
3.2 证书签发流程
传统证书签发，流程很规范。我当年在PKI项目里，光是写CSR（证书签名请求）解析就花了两周。流程大致如下：
- 生成密钥对：终端设备本地生成公私钥，私钥不出设备。
- 构造CSR：包含公钥、设备身份信息（DN），用私钥签名。
- 提交给RA：RA审核身份信息，比如设备序列号、MAC地址。
- RA转发给CA：审核通过后，RA将CSR转发给CA。
- CA签发证书：CA用自身私钥对CSR中的公钥签名，生成X.509证书。
- 返回证书：证书通过RA返回给终端设备。
- 设备安装证书：设备存储证书，用于后续TLS握手。
避坑指南：我曾经遇到一个项目，RA审核逻辑写死了“只要CSR格式正确就通过”。结果攻击者伪造了一批设备CSR，CA签了一大堆非法证书。RA的审核不能省，尤其是IoT设备批量注册时。
3.3 吊销机制：CRL与OCSP
证书吊销是PKI里最容易被忽视的环节。很多IoT设备压根不做吊销检查，导致私钥泄露后，攻击者还能用旧证书横行。
3.4.1 CRL（证书吊销列表）
CRL是一份由CA定期发布的“黑名单”。里面列出了所有被吊销的证书序列号。设备或服务端下载CRL后，本地校验。
- 优点：离线可用，一次下载多次查询。
- 缺点：实时性差，CRL更新周期长（小时级甚至天级）。
- IoT痛点：CRL文件可能很大（几MB），IoT设备内存和带宽扛不住。
3.4.2 OCSP（在线证书状态协议）
OCSP是实时查询。设备向OCSP响应器发送请求，查询某个证书是否有效。响应器返回“good”、“revoked”或“unknown”。
- 优点：实时性好，响应快。
- 缺点：必须在线，OCSP响应器可能成为瓶颈。
- IoT痛点：每次TLS握手都要多一次OCSP查询，功耗和延迟都增加。
注意：OCSP Stapling（OCSP装订）可以缓解这个问题——服务器把OCSP响应“装订”在TLS握手时一起发给客户端。但IoT设备作为服务端时，支持OCSP Stapling的并不多。
3.4 传统PKI在IoT中的局限性
好了，前面讲了传统PKI的“标准动作”。现在说说为什么它在IoT里“跑不动”。我总结了四个核心问题：
| 局限性 | 具体表现 | 我的亲身经历 |
|---|---|---|
| 资源开销大 | X.509证书体积大（1-2KB），TLS握手耗内存 | 某款MCU只有64KB RAM，跑完整TLS握手直接OOM |
| 吊销机制失效 | CRL太大，OCSP需要联网，设备离线就查不了 | 智能门锁离线时被重放旧证书，门被打开了 |
| 批量注册困难 | 每台设备都要单独生成CSR、审核、签发 | 10万台传感器上线，RA审核人员崩溃了 |
| 信任模型僵化 | 所有设备信任同一个CA，CA被攻破全完蛋 | 某厂商CA私钥泄露，几十万设备需要重新烧录 |
总结一下：传统PKI是为“人-机”或“机-机”在可控网络环境设计的。IoT是“物-云”模式，设备数量大、资源少、网络不稳定。直接套用传统PKI，就像让小学生穿成年人的西装——不合身。
为什么会这样？说白了，传统PKI的假设是“每个终端都有足够的算力、存储和网络带宽”。但IoT设备，尤其是MCU级别的，连浮点运算都费劲，更别说解析ASN.1编码的X.509证书了。
嗯，这里要注意。不是说传统PKI不能用，而是需要“裁剪”和“混合”。比如用轻量级证书格式（CWT/CBOR），或者把吊销逻辑移到云端。这些内容，我们会在后面的章节展开。
最后，我画了一张传统PKI架构的流程图，方便你理解角色之间的关系。
这张图里，实线是证书签发流程，虚线是OCSP查询。你看，传统PKI的流程是“串行”的，每一步都依赖上一步。IoT设备如果网络不稳定，或者RA/VA服务挂了，整个流程就卡住了。
我个人习惯，在做IoT PKI方案时，会优先考虑“离线优先”和“批量操作”。比如预置证书、本地吊销列表、或者用区块链做分布式信任。这些思路，我们后面会详细讲。