国密证书格式规范与双证书架构第03页：证书格式规范与双证书架构

01 · 国密证书格式规范

1.1 规范体系

国密数字证书容器格式遵循X.509 v3标准（与RFC 5280同构），其国内规范层次为：GB/T 20518-2018《信息安全技术 公钥基础设施 数字证书格式》规定证书结构、字段与扩展项的通用要求；GM/T 0015-2012《基于SM2密码算法的数字证书格式规范》规定SM2算法在X.509中的具体编码（算法OID、密钥用法、扩展语义）；GM/T 0014-2012《数字证书认证系统密码协议规范》规定CA系统内部及CA与KM之间的密码协议。三层规范叠加，构成国密证书的完整格式基线。

1.2 算法与签名标识

国密证书通过OID标识算法体系（GB/T 33560-2017《密码应用标识规范》）：

签名验签链路的要点：证书以SM2-with-SM3（OID 1.2.156.10197.1.501）签名，验签时按GB/T 32918.2的Z值规则（以证书主体身份标识计算Z）执行——验签方与签名方的ID默认值不一致是联调失败的常见根因（第2页已述）。

1.3 关键扩展项语义

国密根CA证书（内置国密浏览器/网关信任库）
   └── 国密运营CA证书（SM2-with-SM3签名）
         ├── 服务端签名证书  KeyUsage: digitalSignature
         │                   签名: sm2-with-sm3 (1.2.156.10197.1.501)
         │                   用途: TLCP握手中签名ServerKeyExchange等
         └── 服务端加密证书  KeyUsage: keyEncipherment / keyAgreement
                             用途: 密钥交换时加密预主密钥/密钥协商参数

02 · 双证书架构的制度逻辑

2.1 架构定义

国密PKI要求每个主体持有两张SM2证书：

2.2 为什么必须"一分为二"

双证书不是工程冗余，而是两组相互冲突的法律要求在同一密码载体上的制度化解法：

• 抗抵赖性要求签名私钥"无人可代持"：若签名私钥由CA或KM托管，运营方即可伪造用户签名，电子签名的法律效力（《电子签名法》第十四条：可靠的电子签名与手写签名或盖章具有同等法律效力）将从根本上坍塌。因此签名密钥必须在用户侧生成、由用户独占控制。
• 可用性与监管要求加密私钥"必须可恢复"：若加密私钥仅用户持有，则介质丢失即意味着全部历史密文永久不可读（对企业知识资产与司法取证都是不可接受的）；同时依法监管场景要求能够在授权程序下恢复通信内容。因此加密密钥必须由可信第三方（KM中心）托管，并建立严格的密钥恢复审批流程。

2.3 双证书签发流程

03 · 密钥托管与KM中心

3.1 KM中心的职责

密钥管理中心（KM）是双证书体系的中枢组件，核心职责包括：加密密钥对的生成与加密托管；密钥恢复服务（凭授权流程向证书主体交付加密私钥）；密钥归档与销毁；与CA的密钥交互（按GM/T 0014协议）。KM与CA分离设置是治理上的重要设计——签发证书的CA不掌握加密私钥，掌握私钥的KM不能签发证书，两者形成权责制衡。

3.2 密钥恢复流程与风控

3.3 司法调取场景

加密密钥托管的制度价值在依法调取场景显现：经法定程序，监管/司法机关可凭文书要求KM恢复特定主体的加密私钥以解密历史密文。该能力同时是双刃剑——KM中心自身成为最高价值攻击目标，其物理安全、人员权限、审计完整性必须达到与CA同等级别（商用密码产品检测与密评均将其列为核心测评对象）。

04 · 证书全生命周期治理

4.1 生命周期阶段与治理要点

4.2 吊销机制现状

国密证书吊销体系以CRL（证书吊销列表）为主、OCSP为辅：CA定期发布CRL至CRLDP指定地址，客户端验证时获取并检查。相对国际生态（子课题04所述OCSP软失败、CRLite等演进），国密生态的吊销检查更依赖客户端严格实现与国密浏览器的强制执行；服务端侧目前没有国际生态那样的stapling主流实践，吊销时效性整体弱于CT时代的国际最佳实践——这是国密信任体系值得跟踪改进的方向（第8页展望）。

4.3 生命周期治理的"三账"体系

• 证书台账：全量证书（含历史）的签发、到期、吊销状态登记，与CA对账；
• 密钥台账：密钥对状态（在用/冻结/销毁）、托管位置（介质编号/KM条目）、恢复记录；
• 操作审计账：证书申请、签发、更新、吊销、密钥恢复的全流程留痕——密评要求相关记录与报告保存期限不少于6年（《商用密码应用安全性评估管理办法》第十三条）。

05 · 与国际PKI的架构对比

06 · 高频风险点与对策

07 · 国密证书文件形态与互操作要点

7.1 编码与封装

国密证书沿用X.509 DER编码与PEM Base64封装——PEM文本头（-----BEGIN CERTIFICATE-----）与国际证书完全一致，差异仅在内部的算法OID（1.2.156.10197.1.x系列）、SM2/SM3签名值与密钥用法语义。双证书部署的常见文件命名约定：签名证书/私钥（如 *.sign.crt / *.sign.key）与加密证书/私钥（如 *.enc.crt / *.enc.key）；Tongsuo等组件以独立配置项分别加载两类证书与私钥，混配即握手失败。

7.2 密钥库支持

Java生态已可通过国密扩展密码库存取国密证书：腾讯Kona国密套件（TencentKonaSMSuite，开源）支持PKCS#12与JKS两种格式读写含国密证书的密钥库并提供CRL/OCSP校验；Bouncy Castle提供SM2证书生成、解析与CMS扩展能力。密钥库口令策略、介质保护与"三账"登记要求同第04章介质管理。

7.3 联调前互操作自检清单

• 证书链完整性：根CA→运营CA→实体证书，双证书均须链至同一国密根；
• 算法标识：签名算法OID为sm2-with-sm3（1.2.156.10197.1.501），公钥算法OID为SM2（1.2.156.10197.1.301）；
• 密钥用法：签名证书含digitalSignature，加密证书含keyEncipherment/keyAgreement，严格分离；
• 名称匹配：CN/SAN与实际域名一致，证书有效期覆盖服务期；
• 信任库：客户端信任库已装入正确国密根，无私自增删根证书；
• 格式约定：SM2密文顺序C1C3C2、Z值ID默认值、点压缩格式三方对齐（第2页"三大坑点"）。

本节参考来源（本页）

以下均为真实可查的权威来源，用于支撑本页格式规范与治理事实。