4. 车云PKI体系设计
车云mTLS能否真正落地，关键不在“双方都装了证书”，而在于这套证书由谁签发、层级如何划分、每一级能签发什么、信任边界在哪里。车云PKI体系设计的核心，就是把“谁信任谁、谁签发谁、谁不能签发谁”用可验证的密码学结构固定下来。本节围绕根CA、中间CA、车辆CA、云端CA的层级规划展开，并给出证书策略、路径长度约束与跨域信任模型的具体设计方法。
一、为什么不能只用一个CA
最直观的方案是建一个CA，车辆和云端证书都由它直接签发。但车云场景有三个硬约束：第一，车辆证书数量极大，单品牌量产车可达百万级，且生命周期长达10年以上；第二，车辆端私钥保护能力弱，一旦某批车辆的签发密钥泄露，影响面必须可控；第三，车厂、TSP、云服务商、第三方内容提供商往往分属不同组织，信任不能无差别扩散。因此必须采用分层CA结构，把“信任锚”与“日常签发”分离，把不同域、不同用途的签发权隔离。
二、四层CA层级规划
推荐的车云PKI层级为：根CA（Root CA）→ 中间CA（Intermediate CA）→ 车辆CA / 云端CA → 终端实体证书（车辆证书、云端服务证书）。
- 根CA：整个信任体系的锚点，离线保存，私钥不出硬件密码模块（HSM），有效期建议20～25年。根CA只签发中间CA证书，不签发任何终端证书。
- 中间CA：在线运行，按域或按用途划分。例如“车端中间CA”负责签发车辆CA，“云端中间CA”负责签发云端CA。中间CA是根CA与业务CA之间的缓冲层，便于吊销和轮换。
- 车辆CA：专门签发车辆终端证书，可按车型、批次、生产年份再细分。车辆CA的私钥必须由HSM保护，签发接口只对授权产线或OTA签发服务开放。
- 云端CA：签发云端服务证书，包括TSP网关、OTA服务、消息队列、API网关等。云端CA通常与Kubernetes或服务网格的证书管理集成，支持短周期自动轮换。
这种四层结构的好处是：根CA几乎不参与日常操作，泄露风险极低；中间CA可按域吊销；车辆CA和云端CA各自独立，车端签发故障不会影响云端服务证书的续期。
三、证书策略：每一级到底签什么
层级确定后，必须用证书策略把每一级的权限写死。核心字段包括：
| 层级 | basicConstraints | keyUsage | extendedKeyUsage | 有效期 |
|---|---|---|---|---|
| 根CA | CA:TRUE, pathLen:1 | keyCertSign, cRLSign | — | 20~25年 |
| 中间CA | CA:TRUE, pathLen:0 | keyCertSign, cRLSign | — | 5年 |
| 车辆CA | CA:TRUE, pathLen:0 | keyCertSign, cRLSign | — | 3年 |
| 云端CA | CA:TRUE, pathLen:0 | keyCertSign, cRLSign | — | 2年 |
| 车辆终端证书 | CA:FALSE | digitalSignature, keyAgreement | clientAuth | 1年 |
| 云端服务证书 | CA:FALSE | digitalSignature, keyEncipherment | serverAuth, clientAuth | 90天 |
这里有两个容易出错的点。第一，车辆终端证书的extendedKeyUsage必须包含clientAuth，因为车辆在mTLS中作为客户端；如果车辆还要接受云端下发的指令并建立反向通道，可同时包含serverAuth，但需评估暴露面。第二，云端服务证书建议同时包含serverAuth和clientAuth，因为车云mTLS是双向认证，云端服务在验证车辆的同时也要向车辆证明自己。
四、路径长度约束：pathLen到底怎么设
pathLen是basicConstraints中的关键约束，表示该CA证书之后还能跟随多少个非自签发的中间CA证书。设置原则是“够用且最小”。
- 根CA：pathLen=1。因为根CA下面只允许一层中间CA，中间CA不能再签发下级CA。如果未来需要增加一层区域CA，可改为2，但必须重新评估风险。
- 中间CA：pathLen=0。中间CA只能签发终端实体证书，不能再签发CA证书。这样即使中间CA私钥泄露，攻击者也无法用它派生新的下级CA。
- 车辆CA和云端CA：pathLen=0。它们直接签发终端证书，不再向下授权。
验证时可以用OpenSSL检查证书链：
openssl verify -CAfile root_ca.pem -untrusted intermediate_ca.pem vehicle_cert.pem
# 输出 vehicle_cert.pem: OK 表示路径长度和签名链均合法
# 若中间CA的pathLen被错误设为1，则可能允许非法下级CA通过验证五、跨域信任模型
车云场景中，车厂PKI、TSP PKI、第三方服务PKI往往各自独立。跨域信任不能简单“互相导入根证书”，否则信任范围会无限扩散。推荐三种模型：
- 交叉签名（Cross-Signing）：两个域的中间CA互相签发一张交叉证书，使各自终端证书能被对方域验证。适用于双方长期合作、需要双向mTLS的场景。缺点是吊销复杂，任一方中间CA被吊销都会影响交叉链。
- 桥CA（Bridge CA）：建立一个中立桥CA，各域中间CA与桥CA交叉签名，形成星型信任。适用于多车企、多TSP的生态。桥CA本身不签发终端证书，只做信任转换。
- 显式信任锚列表：车辆或云端只信任一组明确列出的中间CA证书，不导入对方根CA。适用于信任关系少、变更不频繁的场景，实现最简单，但扩展性差。
六、一个可落地的层级参数示例
假设某车企需要支持自有TSP和两家第三方内容商，可采用如下规划：根CA离线，pathLen=1；车端中间CA和云端中间CA在线，pathLen=0；车辆CA按车型分三个实例，pathLen=0，有效期3年；云端CA按环境分生产、预生产两个实例，pathLen=0，有效期2年；车辆终端证书有效期1年，云端服务证书90天自动轮换。第三方内容商不直接进入车辆信任库，而是通过TSP网关的证书转换服务接入，车辆只验证TSP网关证书。
总结来看，车云PKI体系设计的本质是“用层级隔离风险，用策略约束权限，用路径长度限制深度，用跨域模型控制信任边界”。根CA只做锚点，中间CA做缓冲，车辆CA和云端CA各自负责终端签发，pathLen逐级收紧，跨域信任优先走网关转换而非直接共享根。把这四件事定清楚，后续的证书签发、轮换、吊销和mTLS握手才有稳定的信任基础。