GM/T 0015-2023《数字证书格式》标准解读:X.509 兼容框架与国密 OID 约束
概述
GM/T 0015-2023《数字证书格式》于 2024 年 6 月 1 日正式实施,替代 GM/T 0015-2012《基于 SM2 密码算法的数字证书格式规范》。2012 版聚焦 SM2 算法的专项约束,而 2023 版则将视野扩展为通用的数字证书格式总纲,构建了与 X.509 v3 / RFC 5280 完全兼容的框架,同时将国密算法作为框架内的一组具体参数和 OID 进行约束。
核心定位:GM/T 0015-2023 是"证书格式总纲",而非仅针对 SM2。一张 RSA 证书可以符合 2023 版的格式要求,但不能声称符合 2012 版。
标准关系
| 标准编号 | 名称 | 定位 | 状态 |
|---|---|---|---|
| GM/T 0015-2023 | 数字证书格式 | 通用格式总纲(X.509 v3 兼容) | 现行有效(2024-06-01 起) |
| GM/T 0015-2012 | 基于 SM2 密码算法的数字证书格式规范 | SM2 专项约束 | 被代替 |
| GM/T 0006-2023 | 密码应用标识规范 | OID 权威参考 | 现行有效 |
| RFC 5280 | Internet X.509 PKI Certificate and CRL Profile | X.509 v3 基础规范 | 国际基准 |
| RFC 5480 | Elliptic Curve Cryptography Subject Public Key Information | ECC 公钥信息规范 | 国际基准 |
证书基础结构
一张标准的数字证书遵循 ASN.1 DER 编码的 Certificate 结构:
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING
}TBSCertificate 核心字段
TBSCertificate 包含证书的所有语义信息,关键字段包括:
| 字段 | 说明 | 关键约束 |
|---|---|---|
| version | 版本号 | 有扩展项时应为 v3 |
| serialNumber | 序列号 | 正整数,同一 CA 域下唯一 |
| issuer | 颁发者 DN | 至少含 CN、O 等属性 |
| subject | 主体 DN | 非空,或空 Subject + critical SAN |
| validity | 有效期 | notBefore < notAfter,UTC 编码 |
| subjectPublicKeyInfo | 主体公钥信息 | 算法标识 + 公钥数据 |
| extensions | 扩展项(v3) | 仅 v3 证书支持 |
时间编码规则
- 2049 年及以前:使用
UTCTime(格式YYMMDDHHMMSSZ) - 2050 年及以后:使用
GeneralizedTime(格式YYYYMMDDHHMMSSZ) - 统一采用 UTC 时间
DER 编码严格性
证书合规检查不应仅停留在"能否被解析",还应确认以下 DER 编码规则:
| 规则 | 说明 |
|---|---|
| BIT STRING 未使用位 | 必须为 0,否则签名值解析出错 |
| INTEGER 最小编码 | 正整数前不能有冗余的 0x00 前导字节 |
| 时间格式正确 | 根据年份选择 UTCTime 或 GeneralizedTime |
| SET 排序 | SET 内元素应按标签升序排列 |
| 扩展唯一性 | 同一 OID 的扩展在同一证书中只能出现一次 |
扩展项约束
证书的功能由扩展项共同定义。以下是关键扩展项的语义约束:
密钥用法(KeyUsage)— OID 2.5.29.15
最核心的限制型扩展。检查时不仅要看是否存在,还要看具体比特位是否与证书用途匹配。
| 证书类型 | 预期 KeyUsage |
|---|---|
| CA 证书 | 至少包含 keyCertSign,通常还含 cRLSign |
| 签名类终端实体证书 | 必须包含 digitalSignature |
| 加密/密钥交换证书 | 检查 keyEncipherment、dataEncipherment、keyAgreement |
基本约束(BasicConstraints)— OID 2.5.29.19
区分"能否当 CA 用"的硬性字段。带 keyCertSign 的证书,BasicConstraints.cA 必须为 TRUE。终端实体证书声明自己是 CA,或 CA 证书声明不是 CA,均为语义矛盾。
使用者密钥标识符(SKI)— OID 2.5.29.14
标识"这张证书里的公钥是谁"。CA 证书尤其重要,因为下游证书的 AKI 靠它完成链路定位。
授权密钥标识符(AKI)— OID 2.5.29.35
CA 签发的证书应包含 AKI 中的 keyIdentifier 字段,用于证书链构建。自签根证书可以例外。
证书策略(CertificatePolicies)— OID 2.5.29.32
回答"这张证书依据什么策略签发"。检查要点:策略 OID 是否可解释,是否附带 CPS 指针或用户通知。
使用者替代名称(SAN)— OID 2.5.29.17
如果主体名称仅通过 SAN 表达,则 subject 应为空序列,且 SAN 应标记为 critical。这是很多"空 Subject 证书"容易漏掉的点。
扩展密钥用法(EKU)— OID 2.5.29.37
比 KeyUsage 更贴近应用层。应联动 KeyUsage 一起看,避免逻辑冲突。
| 用途 | OID |
|---|---|
| serverAuth | 1.3.6.1.5.5.7.3.1 |
| clientAuth | 1.3.6.1.5.5.7.3.2 |
| codeSigning | 1.3.6.1.5.5.7.3.3 |
| emailProtection | 1.3.6.1.5.5.7.3.4 |
| timeStamping | 1.3.6.1.5.5.7.3.8 |
未知 critical 扩展的处理
根据 RFC 5280 第 4.2 节要求:如果证书使用方遇到无法识别的 critical 扩展,必须拒绝使用该证书。这是合规检查中容易被忽略但至关重要的安全要求。
国密 OID 体系
OID(对象标识符)是区分真假国密证书的关键。GM/T 0006-2023《密码应用标识规范》定义了完整的国密 OID 体系。
签名算法 OID
| OID | 名称 | 适用场景 |
|---|---|---|
| 1.2.156.10197.1.501 | 基于 SM2 和 SM3 的签名 | 标准 SM2+SM3 数字签名 |
| 1.2.156.10197.1.501.1 | 基于 SM2 无证书机制和 SM3 的签名 | SM2 无证书签名 |
| 1.2.156.10197.1.501.2 | 基于 SM2 隐式证书机制和 SM3 的签名 | SM2 隐式证书签名 |
| 1.2.156.10197.1.502 | 基于 SM9 和 SM3 的签名 | SM9 IBC 签名 |
| 1.2.156.10197.1.504 | 基于 RSA 和 SM3 的签名 | RSA+SM3 签名(2023 版新增) |
公钥算法 OID
| OID | 名称 | 说明 |
|---|---|---|
| 1.2.840.10045.2.1 | id-ecPublicKey | 椭圆曲线公钥通用标识 |
| 1.2.840.113549.1.1.1 | rsaEncryption | RSA 公钥算法 |
| 1.2.156.10197.1.301 | sm2p256v1 曲线标识 | SM2 椭圆曲线公钥密码算法 |
SM2 椭圆曲线子类型 OID
| OID | 名称 |
|---|---|
| 1.2.156.10197.1.301.1 | SM2-1 数字签名算法 |
| 1.2.156.10197.1.301.2 | SM2-2 密钥交换协议 |
| 1.2.156.10197.1.301.3 | SM2-3 公钥加密算法 |
| 1.2.156.10197.1.301.4 | 基于 SM2 的无证书机制 |
| 1.2.156.10197.1.301.5 | 基于 SM2 的隐式证书机制 |
| 1.2.156.10197.1.301.6 | 基于 SM2 的协同签名机制 |
椭圆曲线 OID 对比(极易混淆)
| OID | 曲线名称 | 备注 |
|---|---|---|
| 1.2.156.10197.1.301 | sm2p256v1 | 国密 SM2 曲线(真国密证书必须使用) |
| 1.2.840.10045.3.1.7 | prime256v1 / P-256 | NIST 曲线(美国标准,不是 SM2) |
关键区分:>1.2.840.10045.2.1(id-ecPublicKey)是"椭圆曲线公钥"的通用算法标识;1.2.156.10197.1.301(sm2p256v1)才是真正指定"用的是 SM2 曲线"的参数 OID。
真正区分真假国密证书的灵魂是曲线参数 OID,绝不能是 P-256 等曲线 OID。
SM2 证书专项约束
公钥点编码
SM2 证书的公钥应为非压缩椭圆曲线点编码:
04 || X (32 字节) || Y (32 字节)- 首字节应为
0x04(非压缩格式标识) - X 坐标:32 字节
- Y 坐标:32 字节
- 总长度:65 字节
0x02 或 0x03 开头的压缩点应作为显著兼容性风险处理。公钥点有效性验证
公钥点不仅要"长得像",还要"真在曲线上"。严格合规核查应验证:
- X、Y 坐标在合法范围内(0 < X, Y < p)
- 点满足 sm2p256v1 曲线方程:y² = x³ + ax + b (mod p)
- 公钥不能是无穷远点
SM2 签名值编码
SM2 签名值应可解析为 SEQUENCE { INTEGER r, INTEGER s }。
DER 编码长度分析:SM2 签名原始数据为 r、s 各 32 字节共 64 字节,经 ASN.1 DER 编码后长度在 69、70、71、72 字节之间波动。
| 长度 | 原因 |
|---|---|
| 69 字节 | 某一分量以 00 开头且第二字节最高位为 0,前导零被删除(32→31) |
| 70 字节 | 最常见,"岁月静好"型(两个 32 字节)或"互相抵消"型(33+31=64) |
| 71 字节 | 某一分量最高位为 1 补零(32→33),另一分量不变 |
| 72 字节 | r 和 s 最高位都为 1,各补一个 0x00,双双膨胀至 33 字节 |
重要提醒:不应硬编码 70 字节。解析逻辑应兼容四种长度。r、s 值有效性:
- r 和 s 都必须是正整数(不能为 0)
- DER 编码不能有冗余的前导
0x00字节(除非是防止负数解读)
四位置 OID 检查模型
SM2 证书的 OID 检查不能只停在一个位置,必须同时核对四个层面:
| 检查位置 | 检查内容 | 预期 OID |
|---|---|---|
| 位置一:外层签名算法 | Certificate.signatureAlgorithm.algorithm | 应为 1.2.156.10197.1.501 或其 SM2 变体 |
| 位置二:TBS 内签名算法 | TBSCertificate.signature.algorithm | 必须与位置一完全一致 |
| 位置三:SPKI 算法标识 | TBSCertificate.subjectPublicKeyInfo.algorithm.algorithm | 应为 1.2.840.10045.2.1(id-ecPublicKey) |
| 位置四:SPKI 参数 OID | TBSCertificate.subjectPublicKeyInfo.algorithm.parameters | 必须为 1.2.156.10197.301(sm2p256v1) |
实务中最常见的问题:
- 证书签名算法看起来像 SM2/SM3,但主体公钥参数不是 SM2 曲线
- 主体公钥用了 SM2 曲线,但签名算法不是 1.2.156.10197.1.501>
这两种情况都不应被当成标准国密证书。
分层合规检查清单
| 检查层级 | 核心内容 |
|---|---|
| 第一层:结构/安全硬伤 | ASN.1 DER 结构完整、版本号、序列号、主体名称、有效期、签名算法一致性、DER 编码严格性 |
| 第二层:条件必检 | KeyUsage / BasicConstraints 语义一致性、AKI/SKI 链路关系、SAN 的 critical 标记、EKU 与 KU 联动 |
| 第三层:国密专项 | 四位置 SM2 OID 检查、公钥非压缩点编码(65 字节)、公钥点在曲线上、签名值 SEQUENCE {r, s} 结构、签名值长度 69-72 字节 |
| 第四层:建议增强 | CertificatePolicies 策略体系、NameConstraints(复杂 CA 体系)、策略映射和限制 |
参考来源
- GM/T 0015-2023《数字证书格式》(2024-06-01 实施)
- GM/T 0015-2012《基于 SM2 密码算法的数字证书格式规范》(被代替)
- GM/T 0006-2023《密码应用标识规范》
- GB/T 20518-2006《信息安全技术 公钥基础设施 数字证书格式》
- RFC 5280 — Internet X.509 PKI Certificate and CRL Profile
- RFC 5480 — Elliptic Curve Cryptography Subject Public Key Information
- GM/T 0002-2012《SM2 椭圆曲线公钥密码算法》
- GM/T 0003.2-2012《SM2 第 2 部分:数字签名算法》
相关实践
- 如需了解国密证书在 TLS 中的实际部署流程,请参阅《SM2 国密算法实战:从编译国密 OpenSSL 到生产级 TLS 完整部署》
- 如需了解国密 HTTPS 部署中的常见问题,请参阅《国密 HTTPS 踩坑实录:从开发到上线的 12 个血泪教训》