国密 HTTPS 的"最后一公里":从证书管理到加密服务的架构转型

PKI 体系 · 2026-06-21 · 8 阅读

前言:国密改造的痛点正在变

过去十年,国密改造的核心问题一直是:如何申请一张 SM2 证书?

到 2026 年,这个问题已经有了相当成熟的答案——ACME 协议(RFC 8555)的 Python 实现、acme.sh 对 SM2 的支持、各类 CA 的自动化申请接口,都已经可用。(参见《ACME 协议实战:用 Python 构建自动化证书管理工具,应对 47 天有效期挑战》和《47天证书时代下的国密双证书自动化部署》。)

但一个更深层的问题正在浮现:证书拿到了,然后呢?

  • Nginx 需要支持 SM2/SM3/SM4 密码套件,但原生 Nginx 不支持国密
  • 浏览器需要支持国密,但 Chrome/Edge 的国密支持依赖操作系统证书库
  • CDN 节点不支持国密算法,HTTPS 握手在 CDN 边缘节点就断了
  • 即使 Web 服务器改造完毕,证书续期、双证书管理、密码套件升级仍然是持续负担
这不是"证书管理"的问题,而是"加密生态"的问题。

2026 年 6 月,北京数字认证(BJCA)发布了一篇颇具代表性的文章《证书自动化的本质是自动化交付 HTTPS 加密服务,不是自动化管理 SSL 证书》,提出了一个核心观点:用户需要的是 HTTPS 加密,不是 SSL 证书。

本文认同这个观点,并在此基础上给出一个可落地的架构方案和完整实现。

一、问题分析:为什么 CLM 模式在国密场景下走不通

1.1 国际 ACME 方案的前提条件

Let's Encrypt 通过 ACME 协议实现了证书的自动化申请和部署,极大推动了 HTTPS 的普及。但 ACME 能成功,依赖一个已经完备的加密生态

  • Web 服务器(Nginx、Apache、IIS)原生支持 TLS
  • 浏览器(Chrome、Firefox、Safari)原生支持标准密码套件
  • 操作系统(Windows、macOS、Linux)内置根证书库
  • CDN 服务(Cloudflare、Akamai)端到端支持
换句话说,整个生态只需要一张证书,HTTPS 自然就通了。ACME 解决的是"最后一公里"——把证书自动送到这个已经准备好的生态中。

1.2 中国国密生态的现实

中国的国密生态完全不同:

层面国际生态国密生态
Web 服务器原生 TLS 支持需要 Tongsuo/BabaSSL 替换
浏览器标准密码套件需要操作系统国密支持
CDN全链路支持基本不支持国密
操作系统内置国际根证书国密根证书需手动导入
中间件默认支持 TLS大多不支持国密套件
在这种生态下,即使证书自动化申请和部署成功,HTTPS 仍然跑不起来。因为中间的任何一环(Web 服务器、CDN 负载均衡、甚至公司的 WAF 设备)不支持国密算法,握手就会失败。

1.3 传统 CLM 的局限

传统 CLM(Certificate Lifecycle Management)系统的逻辑是:

  • 发现证书
  • 申请/续期证书
  • 部署证书到目标系统
  • 监控到期
这个流程在国密场景下会断裂在第 3 步:CLM 能把证书部署到 Nginx,但 Nginx 本身不支持国密密码套件。证书部署成功 ≠ HTTPS 可用。

更关键的是,在国密改造中,服务器改造的成本远高于证书管理的成本。给一台 Nginx 加上国密支持,需要:

  • 编译安装 Tongsuo(替代 OpenSSL)
  • 配置 ssl_conf 指定国密密码套件
  • 配置 SM2 双证书(签名证书 + 加密证书)
  • 配置 SM3 摘要算法
  • 持续跟踪国密标准的更新
每台服务器都是独立的工作量。如果有 100 台服务器,证书管理自动化了,但服务器改造仍然是 100 次重复劳动。

二、架构转型:加密服务网关

2.1 核心思路

既然"最后一公里"的瓶颈在于服务器侧的国密支持,那就把国密支持集中到一个网关层,让后端服务器完全不需要改造。

架构如下:

CODE
客户端(浏览器/APP)
    │
    │ TLS 握手(国密套件)
    ▼
加密服务网关(Tongsuo + Nginx)
    │
    │ HTTP(内网明文或内部 TLS)
    ▼
后端服务器(无需任何国密支持)

关键优势:

  • 后端服务器不需要安装 Tongsuo、不需要配置国密套件、不需要管理证书
  • 证书集中在网关层管理,续期、升级只在网关上操作一台
  • 国密算法的演进(如未来切换到 PQC)只需升级网关层
  • 适用于多服务器、CDN 不可控、甚至无法改造的老旧系统

2.2 与反向代理方案的差异

有人可能会问:这不就是一个 Nginx 反向代理吗?

表面看确实类似,但"加密服务网关"和"普通反向代理"有本质区别:

维度普通反向代理加密服务网关
密码套件国际 RSA/ECC国密 SM2/SM3/SM4
证书类型单证书SM2 双证书(签名+加密)
TLS 版本TLS 1.2/1.3NTLSP(国密 TLS)或 TLS 1.3 + 国密套件
证书管理手动或 CLM全自动化(ACME + 自动 reload)
高可用通常单主多实例 + 证书同步
监控指标基本 SSL 指标国密握手成功率、证书链完整性

三、实战:用 Tongsuo + Nginx 搭建国密加密服务网关

3.1 环境准备

本文基于以下环境:

  • Ubuntu 22.04 LTS
  • Tongsuo 3.0(原 BabaSSL,基于 OpenSSL 3.0 的国密分支)
  • Nginx 1.24+(编译时链接 Tongsuo)
步骤 1:编译安装 Tongsuo

步骤 2:编译 Nginx 链接 Tongsuo

3.2 生成国密双证书

国密 TLS 需要使用两张证书:签名证书(用于身份认证)和加密证书(用于密钥交换)。

环境说明gmssl >= 3.2.0 提供 Python 原生 SM2 支持,cryptography 44.x 支持 hashes.SM3()不支持 ec.SM2() 密钥生成。需要 SM2 密钥时推荐用 gmssl 库。

3.3 Nginx 配置

3.4 证书自动续期脚本

四、生产环境关键问题

4.1 双证书的正确使用

国密 TLS 的签名证书加密证书有不同的用途:

  • 签名证书:服务器在握手时用它证明自己的身份(替代 RSA/ECDSA 签名)
  • 加密证书:用于密钥协商和数据传输加密
常见错误:两张证书使用相同的密钥对。这是不安全的,违反了 GM/T 0024 的规范要求。两张证书必须使用不同的 SM2 密钥对。

4.2 浏览器兼容性

2026 年的浏览器国密支持情况:

浏览器SM2 支持SM3 支持SM4 支持备注
Chrome(Windows)通过操作系统通过操作系统通过操作系统依赖 Windows 国密模块
Edge(Windows)原生支持原生支持原生支持Windows 10+
Firefox需安装 PKCS#11 模块需配置需配置配置较复杂
Safari不支持不支持不支持macOS 国密支持有限
实际建议:在生产环境中,加密服务网关同时提供国密套件 + 国际套件的并行支持。通过 SNI 检测或 User-Agent 判断,对支持国密的客户端提供国密套件,对不支持的客户端回退到国际套件。

NGINX
# 智能密码套件选择
map $ssl_client_hello_suffix $ssl_suite {
    default "ECDHE-RSA-AES256-GCM-SHA384:TLS_AES_256_GCM_SHA384";
    "~SM2" "ECC-SM2-SM4-GCM-SM3:ECDHE-SM2-SM4-GCM-SM3";
}
注意$ssl_client_hello_suffix 不是标准 Nginx 变量。实际实现中,应基于 ClientHello 扩展做判断,或使用 Tongsuo 提供的 $ssl_client_ciphers 变量。具体语法请参考对应版本的 Tongsuo 文档。

4.3 CDN 场景的解决方案

CDN 是国密改造中最难解决的问题。主流 CDN 服务商的边缘节点大多不支持国密密码套件。

方案 A:CDN 仅做流量转发,TLS 在网关终止

CODE
客户端 → CDN(TCP 转发)→ 国密网关(TLS 终止)→ 后端

这种情况下,CDN 不参与 TLS 握手,只是做 TCP 层的负载均衡。国密 HTTPS 完全在网关层实现。

方案 B:双证书 + CDN 兼容

在 CDN 边缘节点使用国际证书(RSA/ECC),在源站网关使用国密证书。CDN 到源站之间使用国密 TLS。

CODE
客户端 → CDN(国际 TLS,RSA 证书)→ 源站网关(国密 TLS,SM2 证书)→ 后端

五、从"证书管理"到"加密服务"的思维转变

5.1 两种范式的对比

维度证书管理范式加密服务范式
核心对象SSL/TLS 证书HTTPS 加密能力
管理目标证书生命周期加密基础设施
关注指标证书到期时间、续期成功率HTTPS 可用性、握手成功率、延迟
运维主体运维团队 + CLM 工具加密网关 + 自动化平台
扩展性每增加一个应用,重复一次证书部署网关统一接入,后端零改造
密码演进每个应用独立升级网关层统一升级

5.2 什么时候该用哪种范式?

适合"证书管理"的场景:

  • 应用数量少(< 10 个 TLS 端点)
  • 所有应用都在可控的服务器上
  • 服务器原生支持国密或有改造能力
  • 运维团队有精力和技能管理证书
适合"加密服务网关"的场景:
  • 应用数量多(> 10 个 TLS 端点)
  • 存在 CDN、WAF 等中间设备
  • 部分应用部署在无法改造的环境中
  • 需要统一管控密码算法的升级(如未来迁移到 PQC)
  • 合规要求"统一入口、统一审计"

5.3 混合方案:渐进式改造

大多数企业的实际情况介于两者之间。推荐采用混合方案

  • 新系统:直接接入加密服务网关,零改造获得国密 HTTPS
  • 可改造的旧系统:逐步部署国密支持,最终也接入网关
  • 不可改造的系统:通过网关反向代理,网关做国密终止,后端保持 HTTP

六、总结

2026 年 7 月 1 日《电子认证服务使用密码管理办法》施行后,CA 许可制度将进一步规范化,证书的获取和管理将更加有序。但国密改造的真正瓶颈已经不在证书侧——而在整个加密生态的支持

传统 CLM 的"申请-部署-监控"模式在国密场景下存在根本性局限,因为它假设了一个已经完备的加密生态。中国的国密生态还在建设中,这意味着我们需要一种不同的思路。

"加密服务网关"架构的核心洞察是:加密能力应该像电力一样集中供应,而不是每台机器自备发电机。 把国密支持集中到网关层,让后端应用专注于业务逻辑,这是国密改造规模化落地的可行路径。

关键要点回顾:

  • 国密双证书必须使用不同的密钥对,签名证书和加密证书不可混用
  • 加密服务网关把国密支持从应用层剥离到基础设施层,降低改造成本
  • 浏览器兼容需要国密+国际双套件并行,通过 SNI 或 ALPN 智能选择
  • CDN 场景需要在网关层终止国密 TLS,CDN 仅做 TCP 转发
  • 证书续期仍然是基础能力,但只是加密服务的一个组件,而非全部

参考来源