2. PKI 体系架构:CA、RA、VA 的角色与职责

PKI 体系,说白了就是一套“发证、管证、验证”的机制。很多刚入行的朋友容易把 CA、RA、VA 混为一谈,觉得都是“搞证书的”。其实它们分工非常明确。我习惯用一个比喻:CA 是印钞厂,RA 是银行柜台,VA 是验钞机。各管一摊,缺一不可。

下面我们逐个拆解。

2.1 CA(证书颁发机构)—— 信任的根

CA 是整个 PKI 体系的核心。它负责签发证书、吊销证书、维护证书生命周期。你想想看,如果 CA 被攻破了,整个信任链就塌了。所以 CA 的安全要求是最高的。

CA 的核心职责:

  • 签发证书:根据 RA 审核通过的信息,生成 X.509 格式的数字证书。
  • 管理证书生命周期:包括证书的颁发、续期、更新、吊销。
  • 维护 CRL/OCSP:定期发布证书吊销列表(CRL),或提供在线证书状态协议(OCSP)响应。
  • 保护根密钥:CA 的私钥是整个信任链的命根子,必须存储在硬件安全模块(HSM)中。

关键点:CA 不直接面对最终用户。它只信任 RA 提交的请求。这是安全隔离的第一道防线。

我在项目中遇到过一家企业,为了省成本,把 CA 直接暴露在业务网里,结果被勒索软件盯上了。嗯,从那以后,我坚持 CA 必须物理隔离,连网络都要单独拉。

2.2 RA(注册机构)—— 审核与录入

RA 是 CA 的“眼睛和耳朵”。它负责验证申请者的身份,确保提交给 CA 的信息是真实、合法的。RA 本身不签发证书,但它决定了 CA 该不该发。

RA 的核心职责:

  • 身份验证:审核申请者的身份信息,比如企业营业执照、域名所有权、个人身份证等。
  • 请求录入:将验证通过的证书请求提交给 CA。
  • 生命周期管理:处理证书的续期、吊销申请,并通知 CA 执行。
  • 审计日志:记录所有审核操作,以备追溯。
对比维度 CA RA
是否签发证书 是 否
是否接触用户 否 是
安全等级要求 最高(HSM、物理隔离) 高(但可适当放宽)
主要工作 签名、发布 审核、录入

个人经验:RA 的审核流程一定要自动化。我曾经见过一个项目,RA 靠人工核对 Excel 表格,结果漏掉了一个过期域名的续期,导致生产环境证书突然失效。后来我们引入了 API 自动校验,再也没出过类似问题。

2.3 VA(验证机构)—— 实时状态查询

VA 负责回答一个问题:“这个证书现在还有效吗?”它不关心证书是谁发的,只关心证书的当前状态。VA 通常通过 OCSP 响应器或 CRL 分发点来提供服务。

VA 的核心职责:

  • 提供证书状态查询:响应客户端的 OCSP 请求,返回“良好”、“吊销”或“未知”。
  • 缓存 CRL:从 CA 获取最新的 CRL,并缓存到本地,减少对 CA 的直接访问。
  • 高可用性:VA 必须 7x24 小时在线,否则客户端无法验证证书状态,可能导致服务中断。

避坑指南:我曾经遇到一个案例,VA 的 OCSP 响应器没有做负载均衡,高峰期直接被打挂了。结果所有客户端都认为证书“状态未知”,业务全线瘫痪。记住,VA 的可用性比 CA 还重要——CA 可以离线签发,VA 不能离线查询。

2.4 三者的协作流程

为了让你更直观地理解,我画了一张流程图。这张图展示了从申请到验证的完整链路。

CA、RA、VA 协作流程图 CA、RA、VA 协作流程图 用户 / 设备 RA(注册机构) CA(证书颁发机构) VA(验证机构) ① 提交申请 ② 审核通过,提交请求 ③ 签发证书 ④ 查询证书状态 ⑤ 返回状态 说明 实线:证书签发流程 虚线:证书验证流程 CA 不直接面对用户

流程很简单:用户向 RA 提交申请 → RA 审核通过后通知 CA → CA 签发证书返回给用户 → 用户使用证书时,对方通过 VA 查询证书状态。你看,CA 全程不跟用户直接打交道,这就是安全隔离的设计思路。

2.5 部署建议

根据我多年的实施经验,给你几个实在的建议:

  1. CA 必须物理隔离:放在独立机房,甚至断网操作。签发时通过离线介质传递请求。
  2. RA 可以分布式部署:不同部门、不同地域可以部署独立的 RA,但统一对接同一个 CA。
  3. VA 要做集群:至少两台 VA 做负载均衡,避免单点故障。我习惯用 DNS 轮询加健康检查。
  4. 日志审计不能省:RA 和 CA 的操作日志要实时同步到安全审计系统,至少保存 3 年。

一个小技巧:如果你用的是开源 PKI 方案(比如 EJBCA),RA 和 CA 可以部署在同一台服务器上,但生产环境千万别这么干。我见过有人图省事,结果 RA 被入侵后 CA 也跟着沦陷。记住,物理隔离是底线。