SM2 证书链验证：从根证书到业务证书的完整信任链

在国密改造项目中，证书链验证是密码应用合规的核心环节。很多实施人员在面对 SM2 证书时，只知道要"验证证书"，但对验证的具体步骤、技术细节和常见陷阱缺乏系统理解。本文将从密码学原理出发，完整解析 SM2 证书链验证的每一个环节。

1. 证书信任链的基本结构

SM2 证书链遵循 X.509 标准定义的层级信任模型，典型结构为：

[根 CA 证书] → [中间 CA 证书] → [业务证书]
     ↓              ↓                ↓
  自签名         由根 CA 签发      由中间 CA 签发
  (Trust Anchor)  (Intermediate)   (End Entity)

核心原则：每一级证书都通过数字签名建立对下一级的信任。验证方只需信任根证书（Trust Anchor），即可通过链式验证建立对业务证书的信任。

2. 证书路径构建

证书路径构建是验证的第一步，目标是找到从业务证书到根证书的有效路径。

2.1 路径构建算法

RFC 5280 定义了 CertificatePath 构建的基本算法：

输入：业务证书 cert_EE
输出：证书路径 [cert_root, cert_intermediate, cert_EE]

算法：
1. 从 cert_EE 的 issuer 字段获取颁发者标识
2. 在证书存储中查找由该颁发者签发的证书
3. 重复步骤 1-2，直到找到自签名证书（根证书）
4. 验证路径中每对相邻证书满足：issuer(cert_i) == subject(cert_i+1)

2.2 国密场景的扩展

GM/T 0014-2023《数字证书认证系统密码协议规范》要求证书路径构建时必须考虑：

• 双证书场景：部分国密系统采用双证书机制（签名证书 + 加密证书），需要分别构建两条验证路径
• 交叉认证：国密证书与 X.509 证书的交叉认证场景下，路径可能跨越不同信任域
• 证书类型标识：GM/T 0015 要求证书中包含 certificatePolicies 扩展，标识证书类型

2.3 常见构建错误

3. 数字签名验证

证书路径构建完成后，需要对每条边进行签名验证，确认上级证书确实签发了下级证书。

3.1 SM2 签名验证公式

GM/T 0003.2-2012《SM2 密码算法第 2 部分：数字签名算法》定义了 SM2 签名验证过程：

签名生成：

输入：消息 m，私钥 dA
输出：签名 (r, s)

1. 计算 ZA = SM3(ENTL || ID || a || b || gx || gy || px || py)
2. e = SM3(ZA || m)
3. 随机选择 k，计算 (x1, y1) = [k]G
4. r = e + x1 mod n
5. s = (1 + dA)^(-1) × (k - r × dA) mod n

签名验证：

输入：消息 m，签名 (r, s)，公钥 PA = (xA, yA)
输出：true 或 false

1. 计算 ZA = SM3(ENTL || ID || a || b || gx || gy || px || py)
2. e = SM3(ZA || m)
3. 验证 r ∈ [1, n-1], s ∈ [1, n-1]
4. t = (r + s) mod n
5. (x1, y1) = [s]G + [t]PA
6. 验证 R = e + x1 mod n == r

3.2 验证步骤

对证书路径中的每条边 (cert_parent, cert_child)：

1. 提取 cert_parent 的公钥 pubkey_parent
2. 对 cert_child 的 TBS（To Be Signed）字段计算 SM3 哈希
3. 使用 pubkey_parent 验证 cert_child 的签名
4. 验证通过 → 信任传递成立

关键实现细节：

• TBS 字段的序列化必须使用 DER 编码
• 哈希算法必须使用 SM3，不能使用 SHA-256 替代
• 公钥格式必须符合 GM/T 0009-2012 的规定

3.3 常见验证陷阱

4. 有效期与用途检查

签名验证通过后，还需要检查证书的时间有效性和用途约束。

4.1 时间有效性检查

from datetime import datetime, timezone

def check_certificate_validity(cert):
    now = datetime.now(timezone.utc)
    not_before = cert.not_valid_before_utc
    not_after = cert.not_valid_after_utc
    
    if now < not_before:
        return False, "证书尚未生效"
    if now > not_after:
        return False, "证书已过期"
    return True, "证书在有效期内"

国密场景要求：

• GM/T 0015-2023 要求证书必须包含 validity 字段
• 有效期不应超过标准规定的上限（根 CA 证书通常不超过 25 年）
• 建议定期轮转证书，避免长期有效的根证书

4.2 密钥用途检查

X.509 v3 证书通过 keyUsage 和 extendedKeyUsage 扩展约束密钥用途：

4.3 基本约束检查

对于 CA 证书，必须检查 basicConstraints 扩展：

basicConstraints = {cA:True, pathLenConstraint:N}

• cA=True 表示该证书可以签发下级证书
• pathLenConstraint 限制下级 CA 的层级深度

• 根 CA 证书：cA=True，通常不设 pathLenConstraint 或设为较大值
• 中间 CA 证书：cA=True，pathLenConstraint 限制剩余层级
• 业务证书：cA=False 或不包含此扩展

5. 吊销状态验证

证书在有效期内可能因私钥泄露、信息变更等原因被提前吊销。验证吊销状态是证书链验证的必要环节。

5.1 CRL 机制

证书吊销列表（CRL）由 CA 定期发布，包含所有已被吊销的证书序列号：

CRL 结构（X.509 v2）：
- tbsCertList：签名前的 TBS 数据
  - version：CRL 版本
  - signature：吊销算法标识
  - issuer：发布 CRL 的 CA
  - thisUpdate：CRL 发布时间
  - nextUpdate：下次 CRL 发布时间
  - revokedCertificates：吊销证书列表
    - entry[i]：
      - certificateNumber：吊销证书序列号
      - revocationDate：吊销时间
      - crlEntryExtensions：扩展信息
- signatureAlgorithm：签名算法
- signatureValue：CRL 签名

验证步骤：

• 获取最新 CRL（通过 CRL Distribution Points 扩展中的 URL）
• 验证 CRL 签名的有效性
• 检查 CRL 是否在有效期内（thisUpdate ~ nextUpdate）
• 在 revokedCertificates 列表中查找业务证书的序列号

5.2 OCSP 机制

在线证书状态协议（OCSP）提供实时的证书状态查询服务：

OCSP 请求：
- version：协议版本
- requestorName：请求者标识
- requestList：请求列表
  - singleRequest：
    - requestCert：证书标识
      - certificateID：
        - hashAlgorithm：哈希算法
        - issuerNameHash：颁发者名称哈希
        - issuerKeyHash：颁发者密钥哈希
        - serialNumber：证书序列号

OCSP 响应：
- responseStatus：响应状态
- responseBytes：
  - response：
    - version：版本
    - responderId：响应者标识
    - producedAt：响应时间
    - responses：
      - singleResponse：
        - certId：证书标识
        - certStatus：证书状态（good/revoked/unknown）
        - thisUpdate：状态更新时间
        - nextUpdate：下次更新时间
        - revocationTime：吊销时间（如适用）

国密适配：目前国密 OCSP 协议尚无独立标准，实际实现参考 RFC 6960 并结合 GM/T 0010-2023《SM2密码算法加密签名消息语法规范》的消息格式要求。GM/T 0033-2023《时间戳接口规范》定义了时间戳服务的接口要求，可用于 OCSP 响应的时间戳增强，确保响应时间的可追溯性。

5.3 CRL vs OCSP 对比

• 金融、政务等高安全场景：同时支持 CRL 和 OCSP
• 一般应用场景：优先 OCSP，降级使用 CRL
• 离线场景：必须支持 CRL 缓存机制

6. 国密场景的特殊要求

6.1 双证书机制

部分国密系统采用双证书机制，分别为签名和加密分配独立证书：

签名证书链：
[根 CA] → [签名中间 CA] → [签名业务证书]
  ↓            ↓              ↓
 SM2 密钥    SM2 密钥       SM2 签名密钥

加密证书链：
[根 CA] → [加密中间 CA] → [加密业务证书]
  ↓            ↓              ↓
 SM2 密钥    SM2 密钥       SM2 加密密钥

验证要点：

• 两条链必须独立验证
• 双证书的公钥必须来自同一 HSM 设备
• 业务系统需明确区分使用签名证书还是加密证书

6.2 国密 OID 检查

GM/T 0006-2023《密码应用标识规范》规定了国密算法的 OID 映射：

• SM2 证书的 signatureAlgorithm 必须为 1.2.156.10197.1.501
• 证书公钥算法 OID 必须为 SM2（1.2.156.10197.1.301）
• 不支持国际算法混用（如 RSA + SM2 混合签名）

6.3 国密 TLS 证书链

在国密 TLS（GM/T 0024-2023）场景中，证书链验证有特殊要求：

• 密码套件协商：ClientHello 必须包含国密密码套件列表
• 证书类型匹配：服务端证书必须与密码套件匹配（如 SM2 签名 + SM4-GCM）
• 扩展支持：必须支持 signature_algorithms 扩展，仅包含国密算法

7. 验证流程总结

完整的 SM2 证书链验证流程如下：

开始
  ↓
1. 获取证书路径 [cert_root, cert_intermediate, ..., cert_EE]
  ↓
2. 验证路径完整性（无缺失、无循环）
  ↓
3. 对每条边进行签名验证
   ├─ 提取上级证书公钥
   ├─ 计算下级证书 TBS 的 SM3 哈希
   └─ 验证 SM2 签名
  ↓ 全部通过
4. 检查有效期（notBefore ≤ now ≤ notAfter）
  ↓ 通过
5. 检查密钥用途（keyUsage、extendedKeyUsage）
  ↓ 通过
6. 检查基本约束（basicConstraints）
  ↓ 通过
7. 检查吊销状态（CRL 或 OCSP）
  ↓ 通过
8. 验证国密 OID（算法标识正确）
  ↓ 通过
验证通过，信任建立

8. 常见实现错误

8.1 忽略证书用途检查

很多实现只验证签名和有效期，忽略了 keyUsage 检查。这可能导致：

• 用于签名的证书被用于密钥传输
• 业务证书被用于签发下级证书

8.2 不当的信任锚配置

错误地将中间 CA 证书作为信任锚，会导致：

• 无法验证中间 CA 的上级证书
• 可能绕过吊销检查

8.3 吊销检查超时处理

网络故障时，吊销检查可能超时。常见错误处理：

• ❌ 直接跳过吊销检查（安全隐患）
• ✅ 根据安全策略决定：严格模式拒绝连接，宽松模式允许但记录告警

9. 相关实践

• SM2 证书链验证 Python 实现
• 国密 TLS 协议详解
• X.509 证书标准解读

参考

• GM/T 0003.2-2012《SM2 密码算法第 2 部分：数字签名算法》
• GM/T 0015-2023《数字证书格式》
• GM/T 0006-2023《密码应用标识规范》
• RFC 5280《Internet X.509 Public Key Infrastructure Certificate and CRL Profile》