国密SSL双证书握手实战：基于GmSSL的TLCP协议实现与OpenSSL对比

1. 项目概述：为什么我们需要关注国密SSL与双证书握手？

如果你最近在对接一些金融、政务或者对数据安全有特殊要求的系统，大概率会遇到一个词：“国密”。不是国际密码，而是国家商用密码标准。简单来说，这是一套我们自己的密码算法和协议体系，核心算法包括SM2（非对称加密）、SM3（哈希）、SM4（对称加密）。而“国密SSL”，就是基于这套国密算法栈实现的SSL/TLS协议。

我最初接触国密SSL，是因为一个银行的项目。对方要求通信链路必须支持国密算法套件，并且明确要求使用“双证书”模式进行身份认证。当时用主流的OpenSSL试了一下，发现它原生并不支持国密算法套件，更别提双证书这种特殊流程了。折腾了一圈，最终找到了GmSSL这个开源项目，它完整实现了国密算法和国密TLCP协议，是进行国密相关开发和测试的利器。

这个项目标题“国密SSL实战：用GmSSL实现双证书TLS1.2握手（附OpenSSL对比）”，就精准地指向了三个核心痛点：第一，如何在一个实际环境中搭建并运行国密SSL；第二，如何理解并实现“双证书”这个关键且特殊的认证机制；第三，作为对比，用我们熟悉的OpenSSL做同样的握手，过程有何不同？这不仅能帮你完成合规需求，更能让你从协议层面理解国密SSL的设计思路。

所以，无论你是运维工程师需要配置国密网关，还是开发者在写需要国密通信的客户端/服务端，或者是安全研究员想了解协议细节，这篇从环境搭建到抓包分析、从GmSSL实操到OpenSSL对比的完整记录，都能给你一份可复现的参考。

2. 核心概念解析：国密算法、双证书与TLCP协议

在动手之前，我们必须把几个关键概念掰扯清楚。这就像盖房子前得认识砖、水泥和钢筋，不然代码和配置摆在你面前也是一头雾水。

2.1 国密算法三剑客：SM2, SM3, SM4

国密算法不是一个算法，而是一个体系，其中最常用的三个是：

• SM2: 基于椭圆曲线密码（ECC）的非对称加密算法，用于数字签名和密钥交换。你可以把它理解为国密版的RSA或ECDSA。但它的曲线参数、签名格式和RSA/ECDSA不同，所以和它们互不兼容。一个常见的误区是认为SM2只是ECC换了个曲线，实际上其签名算法（如SM2-with-SM3）和加密算法都有自己特定的格式。
• SM3: 密码杂凑算法，生成256位的哈希值。功能上对标SHA-256，但算法结构不同，抗碰撞性等密码学强度有自身的设计考量。
• SM4: 分组对称加密算法，分组长度和密钥长度均为128位。工作模式支持ECB、CBC、CFB、OFB、CTR等，对标AES-128。

在TLS协议中，这些算法被组合成特定的“密码套件”。一个国密SSL密码套件看起来可能是这样的：ECC-SM2-WITH-SM4-SM3。这表示使用SM2进行密钥交换和身份认证，使用SM4进行对称加密，使用SM3进行消息认证。

2.2 双证书机制：签名证书与加密证书分离

这是国密TLCP协议（及一些金融规范）中的一个核心特性，也是和传统RSA/ECDSA单证书模式最大的不同。

• 签名证书：专门用于身份认证和生成数字签名。私钥用于签名，公钥放在证书里交给对方验证。这个证书的密钥对通常由实体自己生成并保管签名私钥，强调不可抵赖性。
• 加密证书：专门用于密钥交换过程中的数据加密。例如，在握手时，客户端会用服务端的加密证书公钥来加密预主密钥。这个证书的密钥对有时可以由CA或密钥管理系统生成，加密私钥可能被更严格地托管。

为什么要分开？主要出于安全和管理上的考虑：

1. 职责分离：签名密钥用于长期身份认证，使用频率相对低；加密密钥用于每次会话的密钥交换，使用频率高。分开后，即使加密私钥因高频使用而泄露，也不会影响签名身份的安全性。
2. 密钥生命周期管理：两种证书可以设置不同的有效期和更新策略。
3. 合规与审计：在一些高安全场景下，加密私钥的存储和使用可能有更严格的管控要求。

在握手协议中，服务端会在Certificate消息中连续发送两张证书，第一张是签名证书，第二张是加密证书。客户端需要能够正确解析并使用它们。

2.3 TLCP协议与TLS 1.2

TLCP是“Transport Layer Cryptography Protocol”的缩写，即《GB/T 38636-2020 信息安全技术 传输层密码协议》。你可以把它理解为国密算法版的TLS 1.2协议。它在协议框架上基本遵循TLS 1.2，但做出了关键修改：

1. 强制双证书：如上述，服务端必须提供签名和加密双证书。
2. 固定的密码套件：协议定义了必须支持的国密算法套件，如ECC-SM2-WITH-SM4-SM3和ECDHE-SM2-WITH-SM4-SM3。
3. 密钥交换流程调整：对于静态SM2密钥交换（非ECDHE），密钥交换消息的格式和计算方式与RSA密钥交换不同。
4. 签名算法：必须使用sm2sig_sm3（即SM2-with-SM3）。

因此，一个支持TLCP的对端（如GmSSL），和一个仅支持标准TLS 1.2的对端（如普通OpenSSL），是无法直接建立连接的，因为它们协商的密码套件列表和证书格式根本不匹配。

3. 环境搭建与工具准备：GmSSL编译与OpenSSL对比环境

理论清楚了，我们开始动手。整个实战需要在Linux环境下进行（我使用的是Ubuntu 20.04），主要工具就是GmSSL和OpenSSL，并用Wireshark抓包分析。

3.1 编译与安装GmSSL

GmSSL是北京大学开源的项目，GitHub上可以找到。不建议使用系统包管理器安装可能存在的旧版本，自己编译能确保获得最新功能和支持。

# 1. 克隆代码库 git clone https://github.com/guanzhi/GmSSL.git cd GmSSL # 2. 创建构建目录并配置 mkdir build cd build # 关键配置项：安装到/usr/local/gmssl， 启用静态库，禁用无关模块加快编译 ../configure --prefix=/usr/local/gmssl --enable-static --disable-docs # 3. 编译并安装 make -j$(nproc) # 使用多核编译加快速度 sudo make install # 4. 将GmSSL添加到环境变量，避免与系统OpenSSL冲突 echo 'export PATH=/usr/local/gmssl/bin:$PATH' >> ~/.bashrc echo 'export LD_LIBRARY_PATH=/usr/local/gmssl/lib:$LD_LIBRARY_PATH' >> ~/.bashrc source ~/.bashrc # 5. 验证安装 gmssl version

执行gmssl version应该输出类似“GmSSL 3.1.0”的信息。这里有个关键点：gmssl命令被设计成与openssl命令兼容的子集，所以很多openssl的子命令（如genpkey,req,s_server,s_client）在gmssl中同样可用，但它内部使用的是国密算法。

注意：编译时如果遇到缺失的依赖（如perl），根据报错提示安装即可。--enable-static参数在某些需要静态链接的场景下有用，如果只是动态链接，可以不加。

3.2 准备对比环境：系统OpenSSL

大多数Linux系统自带OpenSSL。我们用它来作为对比实验的服务端/客户端。

openssl version

确保版本在1.1.1以上即可。我们的目的是用OpenSSL搭建一个标准的RSA证书的TLS 1.2服务，用来和GmSSL的国密双证书服务对比握手过程。

3.3 证书生成：生成SM2双证书与RSA单证书

这是核心步骤。我们需要生成两套证书：

1. 国密SM2双证书（用于GmSSL服务端）。
2. 传统RSA证书（用于OpenSSL服务端，作为对比）。

3.3.1 生成国密SM2双证书链

国密证书通常使用SM2密钥和SM3哈希。我们需要生成一个自签的根CA，然后用它来签发服务端的签名证书和加密证书。

# 创建工作目录并进入 mkdir -p gmssl_certs && cd gmssl_certs # 1. 生成SM2根CA私钥和自签证书 gmssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:sm2p256v1 -pkeyopt ec_param_enc:named_curve -out ca.key gmssl req -new -key ca.key -out ca.csr -subj "/C=CN/ST=Beijing/L=Beijing/O=Test GmSSL CA/CN=Test Root CA" gmssl x509 -req -in ca.csr -signkey ca.key -sm3 -out ca.crt -days 3650 # 2. 生成服务端签名证书密钥对和CSR gmssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:sm2p256v1 -pkeyopt ec_param_enc:named_curve -out server_sign.key gmssl req -new -key server_sign.key -out server_sign.csr -subj "/C=CN/ST=Beijing/L=Beijing/O=Test Server/CN=server.gmssl.test" # 3. 生成服务端加密证书密钥对和CSR gmssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:sm2p256v1 -pkeyopt ec_param_enc:named_curve -out server_enc.key gmssl req -new -key server_enc.key -out server_enc.csr -subj "/C=CN/ST=Beijing/L=Beijing/O=Test Server/CN=server.gmssl.test" # 4. 用根CA分别签发两张服务端证书 gmssl x509 -req -in server_sign.csr -CA ca.crt -CAkey ca.key -CAcreateserial -sm3 -out server_sign.crt -days 365 -extfile <(printf "keyUsage=digitalSignature,nonRepudiation\nbasicConstraints=CA:FALSE") gmssl x509 -req -in server_enc.csr -CA ca.crt -CAkey ca.key -CAcreateserial -sm3 -out server_enc.crt -days 365 -extfile <(printf "keyUsage=keyEncipherment,dataEncipherment,keyAgreement\nbasicConstraints=CA:FALSE") # 5. 将两张证书合并为一个文件，供GmSSL服务器使用（签名证书在前，加密证书在后） cat server_sign.crt server_enc.crt > server_double.crt

关键解释与避坑：

• -pkeyopt ec_paramgen_curve:sm2p256v1：这是指定生成SM2曲线参数的关键。如果只写-algorithm EC，默认可能是secp256k1等曲线，导致不是SM2算法。
• -sm3：在x509命令中指定使用SM3作为签名哈希算法。这是生成国密证书必须的选项，缺省可能是SHA256。
• -extfile：我们通过这个参数为证书设置了扩展密钥用法。这是双证书的灵魂所在。
  • 签名证书的keyUsage包含digitalSignature（数字签名）和nonRepudiation（不可否认）。
  • 加密证书的keyUsage包含keyEncipherment（密钥加密）、dataEncipherment（数据加密）和keyAgreement（密钥协商）。
  • 客户端在验证证书时，会检查这些扩展项，确保证书被用于正确的用途。如果混用，握手会失败。
• 最后合并证书server_double.crt时，顺序必须是签名证书在前，加密证书在后。GmSSL的s_server在读取时会按顺序解析。

3.3.2 生成传统RSA证书（用于对比）

这个过程我们更熟悉，用OpenSSL完成。

# 返回上级目录，创建对比用的证书目录 cd .. mkdir -p openssl_certs && cd openssl_certs # 生成RSA私钥和自签证书（一次性命令） openssl req -x509 -newkey rsa:2048 -nodes -keyout server.key -out server.crt -days 365 -subj "/C=CN/ST=Beijing/L=Beijing/O=Test OpenSSL Server/CN=server.openssl.test"

这样我们就有了一个标准的、单证书的RSA密钥对。

4. 实战演练：启动服务与抓包分析握手过程

现在，我们同时启动两个服务，并用客户端连接，同时用Wireshark抓包。

4.1 启动GmSSL国密双证书服务

在一个终端中，运行：

cd /path/to/gmssl_certs gmssl s_server -accept 8443 -key server_sign.key -cert server_double.crt -enc_key server_enc.key -enc_cert server_enc.crt -cipher ECC-SM2-WITH-SM4-SM3 -tls1_2 -www

参数详解：

• -accept 8443: 监听8443端口。
• -key server_sign.key: 指定签名证书的私钥。这是必须的，因为ServerKeyExchange等签名消息需要用这个私钥。
• -cert server_double.crt: 指定证书链文件，这里是我们合并的双证书文件。
• -enc_key server_enc.key:显式指定加密证书的私钥。这是GmSSL支持双证书的关键参数，标准OpenSSL没有这个参数。
• -enc_cert server_enc.crt:显式指定加密证书文件。虽然-cert里包含了，但这里再指定一次有助于内部逻辑处理。
• -cipher ECC-SM2-WITH-SM4-SM3: 强制使用这个国密密码套件。
• -tls1_2: 强制使用TLS 1.2协议。TLCP基于TLS 1.2。
• -www: 发送一个简单的状态页面响应给HTTP请求，方便测试。

4.2 启动OpenSSL RSA单证书服务

在另一个终端中，运行：

cd /path/to/openssl_certs openssl s_server -accept 9443 -key server.key -cert server.crt -tls1_2 -www

这个命令更简洁，因为它使用的是传统的单证书模式。

4.3 使用GmSSL作为客户端进行连接测试

打开第三个终端，我们先测试国密连接。

# 1. 连接GmSSL国密服务（端口8443） echo -e "GET / HTTP/1.0\r\n\r\n" | gmssl s_client -connect localhost:8443 -cipher ECC-SM2-WITH-SM4-SM3 -tls1_2 -CAfile gmssl_certs/ca.crt # 2. 连接OpenSSL RSA服务（端口9443）—— 注意：这里会失败！ echo -e "GET / HTTP/1.0\r\n\r\n" | gmssl s_client -connect localhost:9443 -tls1_2

第一个命令应该成功，输出中会显示“SSL handshake has read ... bytes and written ... bytes”、“Verification: OK”以及最终的HTTP响应。这证明国密双证书握手成功。

第二个命令几乎肯定会失败。错误信息可能是“no shared cipher”或者“sslv3 alert handshake failure”。为什么呢？因为GmSSL客户端默认（或我们指定）的密码套件列表是国密套件，而OpenSSL服务端只支持RSA/AES等国际标准套件，双方找不到共同支持的套件，握手失败。这直观地展示了国密SSL与国际标准TLS的不兼容性。

4.4 使用OpenSSL作为客户端进行连接测试

# 1. 连接OpenSSL RSA服务（端口9443）—— 应该成功 echo -e "GET / HTTP/1.0\r\n\r\n" | openssl s_client -connect localhost:9443 -tls1_2 # 2. 连接GmSSL国密服务（端口8443）—— 这里也会失败！ echo -e "GET / HTTP/1.0\r\n\r\n" | openssl s_client -connect localhost:8443 -tls1_2

第一个命令成功，这是标准TLS握手。第二个命令失败，原因同上：OpenSSL客户端不支持国密套件，无法与GmSSL服务端协商。

4.5 Wireshark抓包深度对比分析

这是理解协议差异最直接的方式。在开始所有测试前，在另一个终端启动Wireshark或tcpdump，捕获loopback接口（lo）上端口8443和9443的流量。

sudo tcpdump -i lo -w tls_handshake.pcap port 8443 or port 9443

分别执行上述4.3和4.4的客户端连接命令后，停止抓包，用Wireshark打开tls_handshake.pcap文件，过滤tls。

观察点1：ClientHello的Cipher Suites

• GmSSL客户端 -> GmSSL服务端：在ClientHello中，你会看到Cipher Suites列表里包含像TLS_ECC_SM4_SM3 (0xe053)这样的值。这是国密套件的IANA临时编码。
• OpenSSL客户端 -> OpenSSL服务端：ClientHello中的Cipher Suites列表是类似TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384等标准套件。

观察点2：ServerHello选中的套件

• GmSSL交互：ServerHello里选中的套件会是TLS_ECC_SM4_SM3。
• OpenSSL交互：选中的会是某个标准套件，如TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384。

观察点3：Certificate消息（最关键的区别）

• GmSSL服务端：点击展开Certificate消息，你会看到两个Certificate结构被依次包含在CertificateList中。第一个证书的扩展密钥用法是Digital Signature, Non-Repudiation；第二个证书的扩展密钥用法是Key Encipherment, Data Encipherment, Key Agreement。这就是双证书在协议层面的直观体现。
• OpenSSL服务端：Certificate消息的CertificateList里只有一个证书结构。

观察点4：Server Key Exchange消息

• 在静态SM2密钥交换（ECC-SM2-WITH-SM4-SM3）中，由于使用了服务端的SM2加密证书公钥，所以不需要Server Key Exchange消息。预主密钥由客户端生成并用服务端加密公钥加密后，在Client Key Exchange消息中发送。这与RSA密钥交换类似。
• 在ECDHE-SM2套件中，则需要Server Key Exchange消息来传递临时SM2公钥等参数。

观察点5：Finished消息的哈希算法

• 整个握手消息的验证，以及Finished消息的计算，使用的都是SM3哈希算法，而不是SHA256。

通过抓包对比，你可以清晰地看到，从ClientHello的套件列表开始，到Certificate消息的结构，再到底层哈希算法，国密SSL握手流程与国际标准TLS 1.2存在系统性差异。这不仅仅是“换了个算法”，而是协议栈层面的适配。

5. 常见问题、排查技巧与进阶思考

在实际操作中，你肯定会遇到各种报错。下面是我踩过的一些坑和解决方法。

5.1 GmSSL常见错误与排查

• gmssl: error: ... no shared cipher

  • 原因：客户端和服务端支持的密码套件列表没有交集。
  • 排查：
    1. 检查服务端启动命令是否用-cipher正确指定了国密套件（如ECC-SM2-WITH-SM4-SM3）。
    2. 检查客户端连接时是否也指定了相同的套件，或者客户端是否支持国密套件。
    3. 用gmssl ciphers -v查看GmSSL支持的所有套件，确认你指定的套件名称正确。
  • 心得：国密套件名称是大小写敏感的，最好直接从gmssl ciphers的输出里复制。

• gmssl: error: ... ssl handshake failure或sslv3 alert handshake failure

  • 这是一个更笼统的错误，可能的原因很多。
  • 排查步骤：
    1. 证书问题优先：这是最常见的原因。确认客户端是否使用了正确的CA证书（-CAfile）来验证服务端证书链。用gmssl verify -CAfile ca.crt server_double.crt验证服务端证书链是否完整且有效。
    2. 双证书匹配：确认服务端启动时，-key指定的私钥是签名证书的私钥，-enc_key指定的私钥是加密证书的私钥，且与-cert、-enc_cert文件匹配。不匹配会导致签名或解密失败。
    3. 密钥用法：用gmssl x509 -in server_sign.crt -text -noout和gmssl x509 -in server_enc.crt -text -noout仔细检查两个证书的X509v3 Key Usage扩展项是否正确（参见3.3.1节）。如果签名证书没有digitalSignature，或者加密证书没有keyEncipherment，握手会失败。
    4. 协议版本：确保双方都使用了-tls1_2。GmSSL可能也支持TLS 1.3，但国密TLCP目前基于TLS 1.2。
    5. 抓包分析：这是终极武器。在Wireshark中查看Alert消息的具体类型，通常会给出更精确的错误原因（如bad_certificate,unsupported_certificate,handshake_failure）。

• gmssl s_server启动失败，提示绑定端口失败

  • 检查端口是否被其他进程占用：netstat -tlnp | grep :8443。
  • GmSSL的s_server在某些版本下可能对参数顺序敏感，确保-accept端口号在命令中位置正确。

5.2 与现有系统集成的考量

• Nginx/Apache支持：要让主流Web服务器支持国密SSL，通常需要重新编译，将OpenSSL替换为支持国密的密码库（如GmSSL、TongSuo等），并修改配置以加载双证书。Nginx的配置中可能需要使用ssl_certificate和ssl_certificate_key指令分别指定合并的证书文件和签名私钥，同时需要通过其他模块或参数指定加密私钥，这通常需要定制的Nginx模块支持。
• 客户端兼容性：你的客户端必须同样支持国密算法套件。对于浏览器，需要安装支持国密的浏览器（如密信浏览器）或扩展。对于移动端APP或Java/Python等语言的客户端，需要使用集成国密算法库的SSL实现（如GmSSL的C库、BouncyCastle的国密Provider等）。
• 双向认证：国密TLCP同样支持双向认证（mTLS）。此时，客户端也需要提供双证书。流程上，服务端在CertificateRequest消息中会请求客户端证书，客户端则在Certificate消息中连续发送自己的签名证书和加密证书。

5.3 性能与调试建议

• 性能：SM2算法基于椭圆曲线，其性能与密钥长度相近的ECDSA/RSA相比各有优劣，具体取决于实现优化。SM4的性能与AES相当。在实际部署前，建议进行压力测试。
• 调试：除了Wireshark，GmSSL和OpenSSL的s_client/s_server工具都提供了丰富的调试选项。
  • -state：打印SSL状态机转换。
  • -debug：输出更详细的调试信息。
  • -msg：以十六进制格式显示所有协议消息。
  • 组合使用这些参数，可以让你对握手过程了如指掌。

6. 总结与资源

通过这一整套从编译、证书生成、服务启动、客户端测试到抓包分析的流程，你应该对国密SSL，特别是双证书握手机制，有了非常直观和深入的理解。核心结论就是：国密SSL不是简单地在OpenSSL里加几个算法，而是一套从算法、证书格式到协议细节都有所不同的完整体系。

关键资源：

• GmSSL项目：https://github.com/guanzhi/GmSSL
• 国密标准文档：GB/T 32918 (SM2), GB/T 32905 (SM3), GB/T 32907 (SM4), GB/T 38636 (TLCP)。这些是理解规范的基础。
• Wireshark：协议分析必备工具，最新版通常已经支持解析国密TLS的密码套件。

最后，个人体会是，国密改造的第一步往往是“环境搭建”和“证书管理”，这两件事理顺了，后面的开发调试就会顺畅很多。尤其是在处理双证书时，一定要理清签名和加密两对密钥证书的用途和匹配关系，一个小的配置错误就可能导致握手失败，而错误信息往往又不那么直观，此时系统地按照证书链验证、密钥用法检查、抓包分析的步骤来排查，是最有效率的方法。