4、PKI架构设计：单层CA vs 多层CA、离线根CA设计原则、在线CA的高可用架构

PKI架构怎么选，说白了就是一句话：你的安全底线在哪，你的运维能力在哪。

我见过不少团队，一上来就搞三层CA，结果根CA证书过期了没人管，CRL分发点配错了半年才发现。也见过直接用单层CA跑生产，私钥泄露后整个PKI重建，那叫一个惨。

这一章，咱们把架构设计的几个核心问题掰开揉碎讲清楚。

4.1 单层CA vs 多层CA：不是越复杂越好

先看一个最基础的对比表格，后面我再细说。

对比维度	单层CA	多层CA（2~3层）
架构复杂度	低，1个CA搞定所有	高，根CA+中间CA+签发CA
私钥泄露影响	整个PKI崩塌，所有证书作废	仅影响该层级及下级，根CA可保留
运维成本	低，一个人能管	高，需要专职团队
适用场景	小规模、内部信任、低风险	大规模、公信力要求高、合规监管
证书链长度	短，验证快	长，验证路径复杂

单层CA，就是只有一个CA，自己给自己签名，然后直接给终端设备发证书。好处是简单，部署快，证书链短。坏处呢？一旦这个CA的私钥泄露，整个信任体系就完了。我在一个创业公司见过这种情况，他们用单层CA跑了两年，后来运维离职时把私钥带走了……嗯，后面的事你懂的。

多层CA，典型的是三层：离线根CA → 策略中间CA → 签发CA。根CA只做一件事——给中间CA签名。中间CA定义证书策略，比如这个CA只发设备证书，那个CA只发用户证书。签发CA才是真正干活的，处理每天的证书请求。

我个人习惯，设备PKI至少用两层。根CA离线，中间CA在线。如果设备量超过10万，或者有多个业务域（比如生产网、办公网、物联网），建议上三层。

4.2 离线根CA设计原则

离线根CA是整个PKI的信任锚点。它一旦出问题，所有下级CA和终端证书都得废。所以设计原则就一条：能不碰它，就别碰它。

具体怎么做？我总结了五个要点。

1. 物理隔离：根CA必须部署在独立的物理机上，不联网，不接USB，不装不必要的软件。最好放在保险柜里，开机需要两人同时在场。
2. 冷存储私钥：根CA的私钥生成后，立即导出到加密硬件（HSM或智能卡），然后从系统中删除明文私钥。日常操作只用HSM签名，私钥永远不离开硬件。
3. 有限生命周期：根CA证书的有效期建议5~10年，但实际签名操作只在前1~2年完成。之后根CA进入休眠状态，不再签发新的中间CA。
4. 严格的签发流程：每次签发中间CA证书，都需要书面审批+双人操作。签发记录要永久保存，包括时间、操作人、证书序列号。
5. 灾难恢复预案：私钥备份要加密存储，分多地保管。我记得有一次帮客户做审计，发现他们的根CA私钥备份就放在同一个机柜里……这跟没备份有什么区别？

4.3 在线CA的高可用架构

在线CA是真正干活的。设备注册、证书续期、CRL发布，都靠它。一旦它挂了，所有新设备入网失败，现有证书无法吊销——这在生产环境里是重大事故。

高可用架构的核心目标：单点故障不影响服务，流量突增不导致崩溃。

我常用的架构是这样的：

┌─────────────────────────────────────────────┐
│               负载均衡器 (LB)                │
│         (健康检查 + 会话保持)                │
└──────────────┬──────────────────────────────┘
               │
      ┌────────┴────────┐
      ▼                 ▼
┌─────────────┐  ┌─────────────┐
│  CA节点 1   │  │  CA节点 2   │
│ (主)        │  │ (备)        │
│ 私钥: HSM   │  │ 私钥: HSM   │
│ 数据库: 本地 │  │ 数据库: 本地 │
└──────┬──────┘  └──────┬──────┘
       │                │
       └────────┬───────┘
                ▼
       ┌────────────────┐
       │  共享数据库     │
       │ (证书/CRL存储)  │
       │ (主从复制)      │
       └────────────────┘

几个关键设计点：

• 无状态CA节点：每个CA节点不保存业务状态，证书请求处理完就写数据库。这样任意节点挂掉，流量切到其他节点，不影响业务。
• HSM共享私钥：所有CA节点使用同一套HSM集群，私钥不出硬件。节点只负责签名请求的转发，不接触私钥明文。
• 数据库主从复制：证书库和CRL库必须做主从复制，主库写，从库读。CA节点写操作走主库，读操作走从库，分担压力。
• 健康检查与自动摘除：负载均衡器每5秒检查一次CA节点的/health端点。如果连续3次失败，自动摘除节点，并告警。

4.4 架构决策流程图

下面这张图，是我做PKI架构设计时常用的决策流程。你可以照着它一步步走，基本不会漏掉关键点。

4.5 避坑指南：我踩过的几个坑

做PKI架构设计这么多年，有些坑真的是拿真金白银换来的教训。分享几个典型的：

• 根CA证书有效期设太短：我曾经设了3年，结果第2年发现中间CA证书链验证失败——因为根CA证书过期了，但中间CA证书还在有效期内。现在我的习惯是根CA设10年，中间CA设5年，签发CA设2~3年。
• CRL分发点配了内网地址：设备在公网时无法验证证书状态。后来我强制要求CRL分发点必须配公网可访问的域名，并且做CDN加速。
• 在线CA的数据库没做读写分离：设备量从1万涨到10万时，数据库成了瓶颈。证书续期请求排队，设备注册超时。后来重构了架构，主库写、从库读，问题解决。
• HSM集群的同步延迟：两个CA节点共用HSM，但HSM之间的密钥同步有延迟。结果节点A签发的证书，节点B验证时找不到公钥。解决方案是HSM集群必须支持实时同步，或者所有节点用同一个HSM主设备。