网银国密SSL改造实战：SM2证书申请与CFCA对接全流程

某银行网上银行密评摸底，网络和通信层面被划了红：门户 HTTPS 用的还是 RSA 证书，加密套件里没有国密算法，证书私钥也托管在普通服务器上。密评意见一句话：等保三级、又是金融关键系统，HTTPS 必须支持国密 SM2，证书链要完整、私钥要进密码设备。先看现场：

# 现场排查：网银 HTTPS 国密支持现状（示意）
# 1) 当前是否支持国密 SM2 套件
echo | openssl s_client -connect $API_HOST:443 -servername ebank.example.com 2>/dev/null | grep -E "Cipher is|Protocol"
# → 输出 TLS_AES_256_GCM... / TLSv1.3 (RSA) → 无国密套件
# → 若输出 TLS_SM2_WITH_SM3_SM4 / 国密套件 → 已支持

# 2) 证书是否为 SM2 国密证书
echo | openssl s_client -connect $API_HOST:443 2>/dev/null | openssl x509 -noout -text 2>/dev/null | grep -E "Public Key Algorithm|Signature Algorithm"
# → 期望 id-ecPublicKey + SM2 签名 → 国密证书
# → 输出 RSA → 国际证书，未做国密改造

网上银行是金融行业对客的第一入口，也是密评「网络和通信层面」检查最勤的地方。国密 SSL 改造的正确姿势，不是简单换个证书，而是走通「SM2 证书申请 → CFCA 对接 → 双算法兼容 → 私钥进设备 → 验证」一整条链路。这篇按清单教程式拆，每步给可复制的命令和注意点，并标明私钥与证书该落在哪套密码产品上——网银 HTTPS 的两对 SM2 私钥托管与证书生命周期，由安当 HSM/KSP 承载，第 1、6 步展开接法：

• 第 1 步：生成 SM2 密钥对与证书请求（CSR）
• 第 2 步：向 CFCA 申请国密 SM2 证书
• 第 3 步：证书转换与证书链补全
• 第 4 步：部署国密 SSL（网关/服务器）
• 第 5 步：双算法兼容：国密浏览器与普通浏览器都能用
• 第 6 步：私钥托管与密钥生命周期管理
• 第 7 步：验证与密评自查清单

第 1 步：生成 SM2 密钥对与证书请求（CSR）

国密 SM2 证书和 RSA 证书的第一个差别在密钥对：SM2 是非对称算法，用的是 SM2 椭圆曲线（sm2p256v1），私钥是 SM2 密钥，不能拿 RSA 的 openssl 命令直接生成。

标准 OpenSSL 对国密算法支持有限，改造环境一般装**国密版 OpenSSL（gmssl）**或用支持国密的密码 SDK。生成密钥对 + CSR：

# 生成 SM2 私钥（不可直接用于导出场景，见第 6 步私钥托管）
gmssl ecparam -genkey -name sm2p256v1 -out sm2_ebank.key

# 生成证书签名请求 CSR
gmssl req -new -key sm2_ebank.key -out ebank.csr \
  -subj "/C=CN/O=某股份制银行/CN=ebank.example.com" \
  -sm2 -sigopt sm2_id_default

# 确认 CSR 的算法是 SM2
gmssl req -in ebank.csr -noout -text | grep -E "Public Key Algorithm|Signature Algorithm"
# → 期望输出 id-ecPublicKey(SM2) / sm2WithSM3

注意点：

• 私钥生成命令里如果后面还要把私钥托管进密码设备，通常让 HSM 直接在设备内生成密钥对（见第 6 步），CSR 由设备导出——这样私钥从生下来就不落应用服务器硬盘
• 银行网银是 OV/EV 级别的对外服务，CN/组织名要和营业执照、备案信息严格一致，CFCA 审核要对公章的

生产形态（推荐）：SM2 密钥对直接在安当 HSM 内生成——私钥只以对象句柄存在于硬件，CSR 由设备导出，服务器上从头到尾没有 .key 明文：

# 在安当 HSM（PKCS#11）内生成 SM2 密钥对，并导出 CSR（示意）
gmssl req -new -provider pkcs11 \
  -key "pkcs11:token=ebank-sm2;object=ebank-sign;type=private" \
  -subj "/C=CN/O=某股份制银行/CN=ebank.example.com" -out ebank.csr -sm2
# → HSM 内多出一个 SM2 私钥对象；服务器本地无任何 .key 文件

关键认知：第 1 步的坑集中在「用 RSA 流程生成 SM2」和「私钥落地应用服务器」两件事。正确姿势是**「私钥进设备生成、CSR 出设备」**——如果你准备用 HSM 托管私钥，这一步就要接 HSM 了。

私钥生成的两条路线，改造前先定：

生产网银务必走设备生成：私钥从「生」就锁在硬件里，服务器上没有任何可导出的私钥明文。这里有个容易被忽视的细节——私钥一旦在服务器上用软件生成过，就等于「出过设备」，即便后面再迁进 HSM，密钥的安全等级也降了一档。所以第 1 步就按生产形态来，别先软生成图省事、上线前再「补救」。

第 2 步：向 CFCA 申请国密 SM2 证书

CFCA（中国金融认证中心）是经国家密码管理局批准、由中国人民银行牵头组建的国家级电子认证机构，国内最早把国密算法商用落地的 CA 之一，签发的 SSL 证书广泛用于银行、证券、保险等强监管行业。网银国密证书走 CFCA，对接的是「信任」：浏览器/密评认 CFCA 的根，你的证书链才被信任。

申请流程：

OV 还是 EV，怎么选：金融对客网银一般直接上 EV 级——审核最严（核验企业法人、营业执照、对公资质），浏览器地址栏信任标识最强，是金融对客场景的通行做法；OV 级审核相对轻、周期短，适合内部系统或非对客渠道。预算允许的情况下，对客网银选 EV，用成本换信任，密评与用户体验两头都拿分。另外如果只是联调验证，可以先走测试证书/预生产流程把链路跑通，再切正式 EV 证书，别拿生产申请流程去练手。

一个必须提前搞清的概念——国密双证书：国密体系里，一张「国密 SSL 证书」往往对应两对证书/私钥，用途不同：

申请时要跟 CA 确认清楚拿到的是几对证书、哪对是签名、哪对是加密，后面部署和私钥管理都依赖这个区分。而且签收回来的证书别急着往服务器上放文件——改造一开始就把「签名私钥/加密私钥各在安当 HSM 里建一个对象、证书对象登记进安当 KSP」定下来（第 6 步展开），否则第 3~4 步做完，又是一地 .key 明文。

# 拿到证书后核对：证书数量与算法（示意）
mkdir -p /opt/ssl/ebank && cd /opt/ssl/ebank
# 期待看到签名证书 + 加密证书两对（4 个组件）：
# sign.cer / sign.key / enc.cer / enc.key  （或统一由 CA 交付说明）
ls -la /opt/ssl/ebank/

关键认知：第 2 步最容易忽略的是**「双证书」概念**——国密改造不是拿一张证书换一张，而是可能要多管理一对密钥。先把证书类型理清，再谈部署，能少走一半弯路。

第 3 步：证书转换与证书链补全

CFCA 交付的证书常是 TXT 文本或邮件附件，直接拿 .cer 文件格式装不上，要经过提取、补链两步：

3.1 提取证书内容

# 把 -----BEGIN CERTIFICATE----- 到 -----END CERTIFICATE----- 之间的 Base64 内容存成 .crt
# （以交付的 TXT 为例，示意命令）
awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/' delivered_sign.txt > sign.crt
awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/' delivered_enc.txt  > enc.crt

3.2 补全证书链

CFCA 是含二级/中级 CA 的体系，只装终端证书不行，浏览器不认。要把根证书 + 中间证书 + 服务器证书组成完整链（fullchain）：

# 拼全链：中间证书在前、服务器证书在后（示意）
cat sign_intermediate.crt sign.crt > sign_fullchain.crt
# 验证证书链完整
gmssl verify -CAfile sign_root.crt sign_fullchain.crt
# → 输出 OK → 证书链完整可用

注意点：CA 的根证书/中间链会周期性更新换代（行业里有 CA 切新一代根证书的先例）。改造部署时务必向 CA 拿当前有效的最新证书链，别拿几年前的旧链硬装——密评和浏览器都会验链。

关键认知：第 3 步的翻车点九成在**「证书链不完整」**——只装了服务器证书、漏了中间证书，浏览器报不受信任、密评验链失败。部署前先用 verify 命令自测一遍，比上线后抓头强。

第 4 步：部署国密 SSL（网关/服务器）

国密 SSL 的部署和普通 HTTPS 有个关键区别：原生 Nginx/主流服务器默认不支持 SM2 套件，需要专门环境。业界两种主流落法：

方案 A：国密网关（推荐，金融对客场景常用）

在网银前置部署国密 SSL 网关/负载均衡（支持国密的安全网关设备），在网关的「国密证书管理」模块分别上传签名证书/私钥、加密证书/私钥：

用户浏览器 ──国密 SM2 套件──▶ 国密 SSL 网关 ──内部/国际算法──▶ 网银应用
   （国密浏览器走 SM2）        （证书/私钥都在这层）            （应用侧改造最小）

网关把国密握手消化在网络入口，应用服务器基本不用动，对存量网银系统最友好，也方便把私钥落在可信设备上。但要钉死一条：私钥不能落在网关硬盘——网关证书可以上传，签名/加密两对私钥应由网关经 PKCS#11 引用 安当 HSM 里的对象；证书对象与到期状态由 安当 KSP 统一登记，哪台网关挂了哪张证书、还剩几天，台账可查。这样网关宕机重装不丢私钥，密评「私钥进密码设备」这一条也稳过。

方案 B：国密版服务器直接支持

用支持国密的 Tengine / 国密 OpenSSL 编译的 Nginx，同时配置签名、加密两套证书并启用国密套件：

# 示意：国密 Nginx/Tengine 双证书配置（非原生 Nginx）
server {
    listen 443 ssl;
    # 签名证书与加密证书两套
    ssl_certificate     /opt/ssl/ebank/sign_fullchain.crt;
    ssl_certificate_key /opt/ssl/ebank/sign.key;
    ssl_enc_certificate     /opt/ssl/ebank/enc_fullchain.crt;   # 国密扩展
    ssl_enc_certificate_key /opt/ssl/ebank/enc.key;
    # 国密加密套件（示意，以实际版本为准）
    ssl_ciphers "ECC-SM2-SM4-CBC-SM3:ECC-SM2-SM4-GCM-SM3:ECDHE-SM2-SM4-CBC-SM3";
    ssl_protocols TLSv1.2 TLSv1.3;
}

# 重载并确认国密套件生效（示意）
nginx -t && nginx -s reload
echo | openssl s_client -connect $API_HOST:443 -servername ebank.example.com -cipher "ECC-SM2-SM4-CBC-SM3" 2>/dev/null | grep -E "Cipher is"
# → 输出 ECC-SM2-SM4-CBC-SM3 → 国密套件可协商 ✓

部署阶段的三个常见坑：

1. 漏配加密证书：只传了签名证书，国密握手报「无可用证书」——双证书两张都要传，缺一张就连不上
2. 套件顺序与协议版本：国密套件没放前面、或环境还开着 TLS1.0/1.1，协商结果不符合预期，注意套件优先级与协议版本一起核对
3. 证书链只放一半：漏了中间证书，浏览器报「不受信任」——测试环境看不出来，生产一上就翻车，先 verify 再上线

关键认知：第 4 步的核心是**「别拿原生 Nginx 硬怼国密」**。两条路要么走国密网关（改造小、入口统一），要么走国密版服务器 + 双证书配置。记住：国密 SSL 是「双证书」，签名/加密两套私钥都要配齐，漏一套就连不上。

第 5 步：双算法兼容：国密浏览器与普通浏览器都能用

国密 SSL 有个绕不开的现实：主流的 Chrome/Edge 等国际浏览器不支持 SM2 套件。如果只部署国密证书，普通浏览器用户直接打不开网银——这在金融场景不可接受。

主流解法是「双算法、双证书」兼容方案：同时挂一张 RSA 证书和一套国密 SM2 证书，让浏览器自己选：

实现上由网关自适应或SNI/算法协商自动分发：国密浏览器命中国密套件，普通浏览器回退 RSA。

# 验证两种浏览器都能协商成功（示意）
# 国密浏览器视角：应看到 SM2 国密套件
echo | openssl s_client -connect $API_HOST:443 -servername ebank.example.com -cipher "ECC-SM2-SM4-CBC-SM3" 2>/dev/null | grep -c "Cipher is"
# → 1 → 国密可协商
# 普通浏览器视角：应回退到 RSA/TLS1.3
echo | openssl s_client -connect $API_HOST:443 -servername ebank.example.com 2>/dev/null | grep -E "Cipher is"
# → 输出 TLS_AES_* / RSA 套件 → 兼容兜底可用

关键认知：第 5 步决定改造**「能不能上线」——纯国密会让普通用户打不开，纯 RSA 过不了密评。「国密合规 + RSA 兜底」双证书**是金融网银的标准答案，改造时把它当成必选项，不是可选项。

第 6 步：私钥托管与密钥生命周期管理

国密 SSL 改造里最容易被密评抓住的，不是套件，是私钥放哪。证书链完整、套件支持国密，但服务器私钥明文躺在应用服务器硬盘上——密评密钥安全照样扣分。

两个动作：

6.1 私钥进密码设备

网银服务器私钥（尤其 EV/签名私钥）应托管进密码设备——直接落 安当 HSM：SM2 签名/加密两对私钥都在 HSM 内生成，通过 PKCS#11 接口调用，私钥生成、存储、握手签名都在硬件内完成，服务器只拿结果，硬盘上不留任何私钥明文：

# 用支持国密的 HSM 生成 SM2 密钥对并导出 CSR（示意）
gmssl pkey -provider pkcs11 -genkey -outform pem 2>/dev/null   # 视厂商 SDK 而定
# 关键判定：私钥不可从设备导出
pkcs11-tool --module /usr/lib/libsm2pkcs11.so --extract -y prvtkey 2>&1 | grep -cE "CKR_ATTRIBUTE|不可导出|denied"
# → >0 → 私钥锁设备，不可导出 ✓

6.2 证书与密钥生命周期统一管

多张国密证书、多对密钥（签名/加密），更要命的是证书会过期——网银证书过期没换，用户直接看到「不安全」。用**密钥管理系统（安当 KSP）**把证书/密钥收口：统一纳管签名证书与加密证书、到期前自动提醒轮换、吊销留痕。

# 自查：在管证书的剩余有效期（示意）
# 查 KSP/证书台账：30 天内到期的证书列表
echo "SELECT cn, not_after FROM certs WHERE not_after < DATE_ADD(NOW(), INTERVAL 30 DAY);" | mysql -ucert -p 2>/dev/null
# → 有行 → 存在临期证书，需安排续期

安当产品在网银国密 SSL 里的完整分工，一张图说清：

国密浏览器 ──SM2 套件──▶ 国密SSL网关 / Tengine（签名+加密双证书）
                                  │ 证书对象（sign/enc）
                                  ▼
       安当 KSP：登记双证书、到期提醒、轮换/吊销策略、审计留痕
                                  │ 私钥对象（PKCS#11，不可导出）
                                  ▼
       安当 HSM：两对 SM2 私钥生成与存储、握手签名在硬件内完成

读图要点：证书是「公之于众」的部分，放网关/服务器没问题；私钥是「秘而不宣」的部分，只以对象形式存在于安当 HSM。网关与服务器通过 PKCS#11 引用私钥完成握手，但永远拿不到私钥本身——这就是密评「私钥进密码设备」这一条在工程上的落地形态。证书台账、到期、轮换、吊销全在安当 KSP，谁家的证书、剩几天、何时换，运维不用靠脑子记。

两类证书的轮换节奏不一样，别一把抓：签名证书换发直接换新即可（旧签名私钥销毁，历史签名本身可长期保留验证）；加密证书换发要考虑历史数据解密——历史报文若仍用旧加密证书加密过，需要保留旧加密私钥用于解密，走「新旧并行过渡」而不是一刀切删除。所以证书台账里要把签名证书与加密证书分开登记到期时间与轮换策略，避免误销毁导致历史数据解不开——这也是国密双证书比单证书多出来的一份运维功课。

关键认知：第 6 步是国密 SSL 改造的「最后一公里」，也最容易被轻视——套件和证书都合规了，私钥没进设备、证书没人管，密评和日常运维照样翻车。私钥托管给 HSM、生命周期归 KSP，才算真正闭环。

第 7 步：验证与密评自查清单

全部落完，对照这份清单逐项验证：

对着这份清单，把你们网银 HTTPS 过一遍：查一次证书公钥算法、试一次国密套件握手、看一眼服务器上还有没有明文私钥。网银国密 SSL 改造的答案是「SM2 证书 + CFCA 对接 + 双算法兼容 + 私钥进设备」——用国密版环境生成 SM2 密钥对、向 CFCA 申请签名/加密双证书并补全链、部署国密网关或双证书服务器、留 RSA 兜底保证普通用户可用，最后把两对私钥托管进 安当 HSM、双证书生命周期交给 安当 KSP，一步不落。你们网银现在卡在哪——还在用 RSA 单证书、证书链没补全、还是私钥还躺在服务器上？评论区说说，一起拆。

文章作者：安当加密技术负责人