理解PKI（五）：CA 如何签发证书，KMC 如何托管加密密钥

前四篇分别讲了 PKI 的整体框架、证书的 DER 编码、X.509 v3 字段，以及证书和私钥如何装进不同容器。把视角从文件移到一套真正运行的证书系统后，问题会变成：

用户提交的身份资料由谁审核？
CSR 通过审核后，谁有权让 CA 私钥工作？
签名私钥和加密私钥都能由服务端保存吗？
证书已经签发，但下载、发布或回调失败，能不能安全重试？
“云端签名”“协同签名”“密钥托管”和“HSM 内生成”究竟是不是一回事？

如果把这些问题都回答成“CA 负责”，系统虽然可能跑通，却很难证明一张证书为什么应该被签发，也很难在失败、作废和密钥恢复时守住边界。

这篇文章不再重复证书字段和 P1/P7 封装，而是建立一条系统主线：

RA 证明申请事实，CA 签署证书声明，KMC 管理可恢复的加密密钥，HSM 保护密码运算，Repository 与状态服务把可验证结果交给使用方。

一、CA 不是一台“盖章服务器”

日常语言中的“CA”常有三种含义：一个电子认证组织、一套证书认证系统，或者系统中真正使用 CA 私钥签发证书的核心模块。讨论架构时，必须先说明指的是哪一层。

一套完整 PKI 至少要回答四个问题：

问题	典型责任方	输出
申请人是谁、资料是否满足策略	RA	审核事实与审批记录
哪个公钥与什么身份、用途绑定	CA	证书、CRL 等签名声明
哪些加密私钥需要备份和恢复	KMC	受保护的密钥及生命周期记录
证书和状态怎样被使用方取得	Repository、CRL/OCSP 服务	可下载、可验证、具有时效的数据

RA（Registration Authority）面向申请人，负责注册、身份鉴别、资料核验和审批。它可以决定一项申请是否满足规则，但不应该直接取得 CA 签发私钥。

CA（Certification Authority）根据已经授权的申请和证书模板生成证书主体，调用受保护的 CA 私钥完成签名，并维护序列号、签发记录和作废状态。

KMC（Key Management Center）处理需要集中管理的密钥生命周期。在传统双证书模型中，它主要管理可恢复的加密密钥，而不是替用户保管用于表达本人意志的签名私钥。

Repository、LDAP、CRL 和 OCSP 服务负责发布证书或状态信息。Repository 本身不必成为新的信任根，因为使用方最终验证的是 CA、CRL 签发者或 OCSP 响应者的签名；但发布系统仍必须保证可用性、新鲜度和访问控制。

这里最重要的不是部署了多少模块，而是每一次跨边界操作都有明确的请求者、授权依据、输入摘要、结果和审计记录。

申请人 / 业务系统
       │ 申请、CSR、身份证明
       ▼
      RA ────── 审核、审批 ──────┐
                                  ▼
                              CA 签发核心 ───► HSM 中的 CA 私钥
                                  │
                    ┌─────────────┼─────────────┐
                    ▼             ▼             ▼
                  证书         CRL/状态记录    审计证据
                    │             │
                    ▼             ▼
             Repository/LDAP   OCSP/CRL 服务

核心层、管理层和服务层分别做什么

国内 CA 系统常用核心层、管理层、服务层描述逻辑边界。它们不是必须对应三台服务器，而是三组暴露面、权限和数据流不同的职责：

逻辑层	典型组件	主要入口与输出	权限和数据边界
服务层	RA、证书下载、LDAP 从目录、OCSP/CRL 查询	接收申请和查询；返回证书与状态信息	面向用户或业务系统，不直接操作 CA/KMC 私钥
管理层	证书管理、安全管理、模板与策略、审批调度、审计	接收审核结果和管理指令；输出经过授权的状态迁移	管理员分权，绑定申请版本，集中记录审计证据
核心层	证书/CRL 签发、主证书库、主目录、KMC 接口	接收已授权的确定输入；输出签名对象和密钥处理结果	位于高安全域，以最小接口访问 HSM 和 KMC

申请通常从服务层进入，经管理层完成身份核验、审批和模板约束，再由核心层执行证书或 CRL 签名。核心层产生的证书和状态数据先写入受控主存储，再同步到服务层的只读副本供外部获取。审计事件则贯穿三层，用同一个申请 ID、证书序列号和操作 ID 串联。

这种分层的价值不是多绕一圈，而是让“能接触申请人”“能批准申请”和“能调用 CA 私钥”不天然落在同一个主体手中。即使小型系统把三层部署在同一套软件中，也应保留角色、接口和审计上的逻辑隔离。

前一篇讲过 PKCS#12 能把私钥和证书装进一个迁移包。这只描述交付结果，不能反推出私钥应该由谁生成。客户端提交 CSR 时，私钥通常在客户端或密码设备中生成，CA 只接收公钥；服务端代生成 P12 时，私钥则曾经进入服务端边界。两种流程的信任模型完全不同。

二、一张证书是如何被签发的

把证书签发理解成一次同步接口调用，会隐藏大量关键状态。更准确的模型是“业务状态机 + 密码操作”。

1. 注册：先建立申请，不急着签名

申请人或业务系统先提交身份信息、证书用途、CSR 或密钥生成方式。RA 为申请分配稳定的申请 ID，记录资料来源、身份鉴别方式和所请求的证书模板。

如果由申请人持有私钥，RA 或 CA 还要验证 CSR 的签名，确认申请者确实控制对应私钥。CSR 签名正确只证明私钥控制，不证明身份证明真实，也不代表申请满足签发策略。

2. 审核：把事实判断变成可追溯授权

审核不应只是数据库里的一个 approved = true。至少应保存：

谁在什么时间依据什么策略审核；
审核时看到的关键申请数据或其不可歧义摘要；
批准的证书模板、主体名称、SAN、Key Usage 和有效期边界；
是否需要第二名审批人，审批人与录入人能否为同一人；
审核后哪些字段仍允许变化。

审批授权的是一组确定输入，不是一个以后还可以任意修改的申请编号。

如果审核完成后还能替换公钥、主体或用途，就可能出现“审核的是 A，签发的是 B”。因此，系统通常要对签发输入做版本化或摘要绑定；发生实质修改时重新审核。

3. 签发：模板约束输入，HSM 完成 CA 签名

CA 取得已批准申请后，结合证书模板形成 TBSCertificate：分配唯一序列号，确定 issuer、subject、有效期、公钥和扩展，然后调用 CA 签名密钥。

生产系统中的 CA 私钥通常由 HSM 或其他受控密码模块生成和使用。应用拿到的是密钥标识或句柄以及签名结果，而不是可复制的明文私钥。

这仍不等于“用了 HSM 就安全”。系统还要明确：

哪些进程和角色可以调用密钥；
密钥允许签证书、签 CRL，还是用于其他操作；
激活密钥需要单人、多人还是外部授权；
备份能否恢复到其他设备，恢复由谁批准；
调用失败、超时或返回后数据库写入失败时如何判定结果。

4. 提交：先确定签发事实，再触发外部副作用

证书签名成功不代表整笔业务已经结束。系统还可能需要写入证书库、更新申请状态、发布到目录、生成下载凭证、发送回调或更新状态服务。

稳妥的实现会把“不可重复的签发决定”和“可以安全重试的分发动作”分开：

APPROVED
   │ 以申请 ID + 输入版本获取签发锁
   ▼
ISSUING
   │ 生成序列号、构造 TBS、调用 CA 签名
   ▼
ISSUED ─────► DISTRIBUTION_PENDING ─────► DISTRIBUTED
   │                 │
   │                 └── 发布、通知、回调可幂等重试
   └── 已存在签发结果时直接返回，不再生成第二张证书

这里的 ISSUED、DISTRIBUTION_PENDING 和 DISTRIBUTED 是示例系统内部的业务处理状态，不属于通用 PKIX 证书状态。证书是否处于有效期、能否构建到信任锚、是否已作废以及用途是否匹配，需要由依赖方独立验证；目录发布完成不会让一张原本无效的证书变得有效。

如果 HSM 已经返回签名，但服务在保存结果前超时，调用方不能简单“再签一次”。需要依靠稳定请求 ID、唯一约束、签发日志或可恢复事务，判断上一次究竟没有执行、已经成功，还是结果未知。

重试的是同一笔业务，不是重新制造一笔签发事实。

三、证书生命周期与密钥生命周期是两条线

证书是有期限、可公开、可作废的声明；私钥是必须控制暴露面、可能需要轮换或恢复的秘密。它们彼此关联，却不能共用一个模糊的“有效状态”。

证书状态	表达的事实	对应密钥可能怎样
申请中 / 待审核	尚未形成 CA 声明	未生成，或已在客户端生成
已签发 / 有效	CA 已绑定身份与公钥	可用、暂不可用或已丢失
冻结 / 暂停	策略上暂不接受证书	密钥通常仍存在
已作废	后续验证应获得作废状态	密钥可能仍需留作取证或解密历史数据
已过期	超过证书声明的时间范围	加密私钥可能仍要解密历史密文

这也是 KMC 中常见“备用、在用、历史”密钥库的原因：密钥从生成、分配、使用到归档有自己的状态迁移，不能因为证书过期就立即销毁。

对于加密证书，历史私钥可能仍是读取旧密文的唯一途径。对于签名证书，验证历史签名主要依赖公开证书、签名值、签署时的状态与时间证据，并不需要恢复签名私钥。

因此，作废证书也不是删除记录。CA 仍需保留证书序列号、作废时间和原因，通过 CRL 或 OCSP 等机制发布状态。RFC 5280 把 CA 提供作废状态列为其职责之一；RFC 6960 则要求客户端验证 OCSP 响应与目标证书的对应关系、响应签名者授权以及 thisUpdate、nextUpdate 等时间信息。

状态服务的详细验证顺序留到第六篇。本篇只强调一点：签发、发布和状态查询是相互衔接的职责，但不应由一个不分权限的超级模块包办。

四、为什么双证书只托管加密私钥

传统双证书体系会为同一主体签发用途不同的两张证书：

类型	主要用途	私钥控制原则
签名证书	身份认证、数字签名	强调本人专有，不应为事后恢复而集中托管完整私钥
加密证书	密钥封装、数据解密	为读取历史密文，可由 KMC 在严格策略下备份和恢复

假设员工使用加密证书接收了一批业务密文，后来设备损坏。如果加密私钥完全不可恢复，这些历史数据可能永久丢失。因此，KMC 可以生成或接收加密密钥，使用密钥加密密钥（KEK）等机制保护库存副本，并在换设备、密钥更新或获准取证时执行恢复。

但签名私钥承担的是“谁控制私钥、谁完成签名”的证明。如果组织能够在申请人不参与时恢复完整签名私钥，就会扩大冒签风险，也会削弱私钥专有控制的边界。

一个典型的双证书交付过程可以抽象为：

客户端生成自己的签名密钥对，并提交签名公钥；
KMC 为加密用途准备一对可恢复密钥，并保存受 KEK 保护的库存副本；
CA 分别为签名公钥和加密公钥签发用途受限的证书；
KMC 使用客户端临时公钥或经认证的安全通道，把加密私钥安全交付到目标载体；
客户端确认导入成功，CA/KMC 分别推进证书与密钥状态；
后续恢复必须经过独立审批、身份复核和完整审计。

这里至少存在三种不同密钥：用户的签名私钥、KMC 托管的加密私钥，以及 KMC 用于保护库存密钥的 KEK。把它们都称为“用户私钥”，会让权限设计迅速失控。

恢复不是数据库导出

一笔合格的密钥恢复需要回答：

恢复什么密钥版本，对应哪张证书和哪段有效期；
为什么恢复，由谁申请、谁审批、谁执行；
恢复给哪个经过认证的目标载体；
交付密文怎样防止被替换、重放或发给错误设备；
是否需要双人控制，恢复后如何通知、审计和处置临时材料。

用户换设备恢复与司法取证也不应复用同一授权入口。两者的申请主体、证据、审批链和交付对象不同，即使底层都调用 KMC，也应是两类业务。

五、协同签名不是把签名私钥交给 KMC

协同签名常被笼统地描述为“私钥一半在手机，一半在云端”。这个说法可以帮助入门，但不足以设计接口。

以两方协同签名为抽象模型，客户端持有一个密钥分量，服务端持有另一个分量；双方通过协议共同形成公钥，并在每次签名时交换中间值，最终得到一个普通验签方可以验证的完整签名。设计目标通常是：单独控制任一分量的一方都不能独立完成签名，也不能仅凭自己的长期分量恢复完整签名私钥。

客户端长期分量                     服务端长期分量
      │                                  │
      ├──── 身份认证、会话绑定、随机数 ────┤
      │                                  │
      ├──── 协同计算的中间值往返 ──────────┤
      │                                  │
      └──────────► 完整 SM2 签名 ◄────────┘
                         │
                         ▼
                 普通公钥即可验签

截至 2026 年 8 月，国家密码管理局第 54 号公告确认，GM/T 0144-2025《基于 SM2 密码算法的协同签名技术规范》和 GM/T 0145-2025《基于 SM2 密码算法的协同签名系统检测规范》已于 2026 年 7 月 1 日实施。公开标准页面能够确认标准名称和实施时间，但本文没有把未取得的标准正文转述为具体条款。密钥生成、协议消息、身份鉴别、随机数、异常处理和检测证据，是实现协同签名时应逐项核对的通用检查维度；具体要求仍以适用标准正文和检测规则为准，不能根据上面的概念图自行实现算法。

四种“拆开密钥”的做法不能混为一谈

做法	拆分的目的	完整密钥在哪里	是否直接参与每次业务签名
协同签名分量	防止单方独立签名	协议设计上不要求还原完整长期私钥	是，双方在线协作
HSM 导入密钥分量	防止单人知道导入密钥	分量在 HSM 内组合为可用密钥	否，导入后由 HSM 使用
门限备份 / 恢复份额	控制灾备和恢复权限	达到门限后可恢复密钥或解锁备份	通常否，只在恢复时使用
KMC 托管加密私钥	保证历史密文可恢复	完整加密私钥以受保护形态存在	用于解密，不用于表达签名意志

协同签名服务端也不等于 CA。CA 私钥签的是证书，协同签名各方使用的是终端主体的签名能力，签的是合同摘要、认证挑战或其他业务数据。即使两者都由 HSM 执行 SM2 运算，也属于不同密钥、不同授权和不同审计域。

协同签名还需要补上算法之外的业务控制：客户端是否完成了可靠身份认证，本次会话是否绑定明确原文或摘要，服务端看到的待签数据能否被替换，用户是否表达了本次签署意愿，超时重试会不会生成两笔签名，分量轮换后旧证书如何处置。密码协议只能解决其中一部分。

六、CA 与 KMC 之间应该怎样设计接口

CA/KMC 接口传递的是高价值状态迁移，不宜设计成“给我一把私钥”或“帮我发张证书”两个宽泛方法。每个请求至少应绑定：

稳定、全局唯一的业务请求 ID；
调用方身份、租户、机构与授权角色；
证书申请 ID、密钥用途和算法参数；
证书模板与关键字段摘要；
目标载体或临时公钥的身份与完整性证明；
时间、随机挑战或防重放数据；
幂等键、结果状态和可关联的审计事件 ID。

1. 用状态查询消除“结果未知”

分布式系统最麻烦的失败不是明确失败，而是服务端已经完成操作、客户端却没有收到响应。

例如，KMC 已经把一把备用加密密钥切换为在用状态，但 CA 因网络超时认为调用失败。若 CA 再次调用“申请密钥”，就可能产生第二把密钥；若直接回滚数据库，又可能让实际已用密钥失去关联。

因此，写操作之外还需要按请求 ID 查询结果：

request_id = 8f...

第一次调用：超时
        │
        ▼
查询 request_id
   ├── NOT_FOUND  → 可以按同一请求重试
   ├── PROCESSING → 等待或继续查询
   ├── SUCCEEDED  → 取得同一结果，不再次生成
   └── FAILED     → 根据明确错误决定修正或终止

2. 不要用共享数据库代替信任协议

CA 直接读取 KMC 数据库看似简单，却绕过了调用方认证、用途限制和完整审计，也把两个安全域绑定到同一种存储实现。

跨模块通信应有双向身份认证、消息完整性、最小授权和重放防护。传递密钥时还要使用针对目标载体的密钥包装或经过认证的安全通道，而不是把“数据库字段已加密”当成完整协议。

3. 审计记录业务语义，不只记录 HTTP 200

审计应能回答“谁依据什么批准了哪次状态迁移”，而不仅是某接口返回成功。关键记录包括申请版本、审批链、使用的模板和密钥标识、证书序列号、操作结果、失败原因、前后状态以及关联请求 ID。

敏感材料本身不应写入日志。私钥、密钥分量、PIN、临时解包密钥和完整身份材料都不能因为“方便排障”进入普通应用日志。

七、运营型 CA 与企业级 CA 的边界

运营型 CA 和企业内部 CA 可以使用相似的软件、HSM 和协议，但它们承担的信任范围不同。

维度	运营型 CA	企业级 CA
服务对象	面向外部客户或社会主体	组织内部人员、设备和系统
信任来源	对外政策、认证服务承诺及适用监管要求	企业治理、内部策略和受管终端
身份审核	多渠道、多机构 RA，责任链更长	可依赖 HR、CMDB、设备管理等内部权威源
状态与发布	面向更广使用方，连续性要求高	可在企业网络和受管客户端内分发
合规与审计	通常承担更严格的外部审计与服务责任	仍需审计，但边界由内部风险和适用规则决定

不能因为企业 CA 只在内网使用，就把 CA 私钥放进普通配置文件、让所有管理员共享账号，或者省略作废服务。反过来，也不能把运营型 CA 的组织规模和全部流程机械复制给一个开发测试环境。

当前 EJBCA 文档仍把 RA、CA 和 Validation Authority 作为不同职责来描述；其外置 RA 模式让 CA 位于更高安全区，由 CA 向低安全区 RA 建立受认证连接，并通过角色限制 Peer 的权限。这说明十多年前书中的“核心区—管理区—服务区”并未过时，但现代实现更强调受认证连接、细粒度授权和可水平扩展的服务边界。

部署时可以沿两条轴检查：一条是信任边界——根 CA、签发 CA、RA、KMC、状态服务分别在哪里；另一条是故障边界——一台主机、一个机房或一条链路故障时，哪些服务停止，哪些密钥仍然安全。

高可用复制的是服务能力和受保护状态，不是把 CA 或 KMC 私钥随意复制到更多普通节点。

八、用一份清单检查证书系统设计

申请与审批

申请有稳定 ID，审核绑定确定的输入版本或摘要；
CSR 控制证明、身份核验和业务授权是三个独立判断；
录入、审核、签发和密钥恢复按风险分权；
模板限制 subject、SAN、KU、EKU、有效期与算法，而不是接受调用方任意字段。

签发与发布

CA 私钥在受控密码模块中使用，应用只获得句柄和签名结果；
序列号唯一，签发请求幂等，结果未知时可以查询；
证书落库、发布、通知和回调具有清晰顺序与补偿机制；
作废不会删除证书，CRL/OCSP 的生成、发布和新鲜度可以监控。

密钥管理

签名私钥、加密私钥、CA 私钥、KEK 和协同签名分量使用不同标识与权限；
只有确有恢复需求的密钥进入托管流程；
备用、在用、历史和销毁状态有明确迁移条件；
用户恢复、司法取证、灾备恢复是不同授权流程；
密钥材料和 PIN 不进入日志、消息队列、普通数据库字段或临时文件。

协同签名

算法和消息流程按适用标准实现，而不是自行设计“半把私钥”；
客户端与服务端分量均有设备绑定、轮换、吊销和异常处置；
每次签名绑定用户身份、签署意愿、原文摘要和会话；
超时、重试和中间值异常不会绕过授权或重复签署；
协同签名服务与 CA、KMC 的密钥和审计域明确分离。

九、总结

证书系统最危险的设计误区，是把所有密码能力都放进一个“CA 服务”，再用数据库状态掩盖职责差异。

真正清晰的边界是：RA 对申请事实负责，CA 对证书声明负责，KMC 对可恢复加密密钥负责，HSM 对密钥使用边界负责，发布与状态服务对可获得性和新鲜度负责。证书和密钥各有生命周期，每次跨状态迁移都需要授权、幂等、失败恢复和审计。

CA 证明“这个公钥属于谁、允许做什么”；KMC 保证“需要恢复的加密能力不会随设备一起丢失”；协同签名解决“任何单方都不应独立完成这次签名”。

下一篇将站到证书使用方一侧，回答另一类经常被“证书有效”四个字掩盖的问题：如何构建到信任锚的路径，怎样检查 CRL/OCSP 状态与新鲜度，以及为什么技术验证通过仍不等于业务授权成立。

参考资料

现行资料核验于 2026-08-05。书中 RFC 3280、RFC 2560 以及 2015 年的 OpenSSL/EJBCA 部署只作为历史线索；当前 PKIX、OCSP、协同签名标准和产品行为以以上官方资料及目标环境为准。

系列文章

笔记整理自《PKI、CA 与数字证书技术大全》第四部分第 14～18 章，并按现行 RFC、密码行业标准、EJBCA 与 PKCS#11 官方文档校正和补充。