1. 方案背景与整体设计思路拆解

1.1 等保测评里“传输安全”到底卡在哪

这几年凡是要过等保三级测评的Web系统，几乎都会遇到同一个问题：测评项里对通信传输的机密性和完整性有明确要求，检查人员会实际抓包看协议、看证书、看加密套件。过去只开个HTTPS、用RSA证书就能应付过去的日子，现在开始行不通了，因为国密合规这一条被越来越多地区、行业纳入实际评分项。说白了，测评现场会直接问你：这个HTTPS用的是不是国密算法？证书是不是SM2体系的？如果答案是否定的，那这一项基本就是整改意见。

很多团队的第一反应是“那我改代码啊”，把TLS库换成国密版本，在Python应用里加ssl_context。但真上手就会发现问题：业务代码几百个接口，测试环境一堆依赖，还有第三方回调、WebSocket、内部服务调用，全都牵扯TLS握手逻辑。改到一半往往就炸了，要么某些库不支持国密套件，要么底层OpenSSL版本冲突，改完还得整个回归，上线排期直接往后拖一个月。

实际上等保三级要求的是“通信传输过程使用符合国密标准的加密通道”，它没说一定要在应用进程里完成这件事。网络接入层把国密SSL终结掉，后端走内网明文或者普通TCP，只要整体对外呈现的是一条国密加密链路，这在实务上是可以被接受的。这也是“零改造接入”这类方案能立足的根本原因——不是绕过合规，而是把密码学的复杂度从应用代码里剥离出来，交给更擅长处理这一层的网关组件。

1.2 为什么选择“零改造”而不是应用内改TLS

我做过的几个项目里，凡是尝试在应用层强行套国密SSL的，最后都会遇到一类问题：Python框架和第三方库对国密套件的支持参差不齐。有的库静态编译时没开国密分支，有的库对SM2证书链校验的实现不完整，调试的时候经常是“客户端连接成功，但服务端日志里一堆未知错误”，根本分不清是证书问题还是算法实现问题。

零改造方案的核心思路是把国密SSL终结在接入层。对外，Nginx监听443端口，使用国密双证书，与客户端完成SM2密钥协商、SM4加密通信；对内，Nginx通过unix socket或回环地址连到uWSGI进程，uWSGI依然使用最普通的wsgi协议接收请求，Python代码完全感知不到外面发生过什么。整个过程对应用来说，就像有人在门口装了一道加密门禁，屋里的人该干嘛还是干嘛。

这个方案的第二个优势是可控性。应用层不碰TLS，意味着将来国密标准更新、证书升级、密码库替换，都只影响Nginx和配套组件，不回滚到业务代码。对一个长期维护的服务来说，这种边界清晰度的价值比省几天工期大得多。第三个优势是性能集中调优。国密算法本身的手持计算开销比国际算法略高，如果在每个Python进程里各做一遍握手，CPU开销分散且难以管理；集中在Nginx一层做，可以统一开会话缓存、做连接复用，效率高得多。

1.3 架构选型与数据流的取舍

整体数据流是这样的：外部客户端发起HTTPS请求到Nginx的443端口，Nginx用国密套件完成握手、解密后，把明文HTTP请求转发给本机或内网机器上的uWSGI，uWSGI再把请求交给Python应用处理，响应原路返回。

这个链路里为什么用uWSGI而不是直接把请求用HTTP转给后端？因为uWSGI和Nginx之间的协议是uwsgi协议，比HTTP少了很多重复解析开销，而且这个协议在Nginx里是原生支持的，配置一个uwsgi_pass就能搞定。uWSGI本身确实内置了SSL能力，但它的SSL模块对国密算法的支持远不如专门构建的Nginx灵活，所以我不会建议用它来做国密终结。它在这个方案里老老实实承担Python进程管理器和协议适配的角色，这就够了。

至于PyCryptodome，它在标题里出现，很多人会误以为它是用来做国密HTTPS的国家算法实现。严谨地说，PyCryptodome并不包含SM2、SM3、SM4这套国密算法的完整实现，它的强项是AES、RSA、ChaCha20这类国际算法以及底层原语。在这个方案里，它是Python应用侧的加密工具箱，负责那些SSL协议之外、但等保要求里同样会检查的环节，比如敏感配置加密、Token签名、密钥派生。真正决定HTTPS是否“国密”的，是Nginx所链接的国密SSL库和SM2证书体系。这个职责边界后面我会专门展开讲，你先记住一个原则：链路各层用各自最擅长的工具。

2. 国密HTTPS落地的算法与证书基础

2.1 SM2、SM3、SM4在HTTPS里各自扮演什么角色

国密HTTPS并不是一种全新的协议，它本质上是把TLS握手过程中的公钥算法、哈希算法、对称加密算法替换为国密算法。你可以这么记：SM2管身份和密钥交换，SM3管完整性校验，SM4管数据加密。

SM2是非对称算法，类似RSA和ECDSA的合体，它既做签名也做密钥交换。在TLS握手时，客户端拿到服务器发送的SM2加密证书后，生成一个随机临时密钥，用服务器的SM2公钥加密后发过去，双方就共享了同一个会话密钥。SM3是哈希算法，类似SHA-256，握手消息的完整性摘要、以及从共享密钥派生出会话密钥的过程，都需要SM3参与。SM4是对称分组算法，类似AES，握手完成之后的大量业务数据，就是用SM4加密传输的。

如果用生活类比，SM2是保险柜的锁，钥匙只有服务器有；SM3是快递箱上的防拆封条，谁动过一望便知；SM4是货品本身的密封包装，保证运输途中内容不被偷看。一套国密HTTPS，就是这三样东西配合工作的结果。

2.2 国密双证书机制与签发实操

国密HTTPS有一个容易让人懵的点：它需要两张证书，一张签名证书、一张加密证书，而不是像国际HTTPS那样一张证书搞定。原因是国密体系把“证明你是谁”和“给别人加密”拆成了两件事。签名证书的密钥对只用于握手过程中的身份认证和消息签名，加密证书的密钥对只用于密钥交换。一旦加密私钥泄露，服务器身份没有直接受损，因为攻击者仍然拿不到签名私钥。

自行搭建测试环境时，可以用支持国密算法的开源工具来签发SM2证书。大致流程是这样：

# 生成SM2加密密钥对 openssl ecparam -genkey -name SM2 -out sm2_enc.key # 生成SM2加密证书请求 openssl req -new -key sm2_enc.key -out sm2_enc.csr -subj "/CN=web.example.test" # 用CA证书签发加密证书 openssl x509 -req -in sm2_enc.csr \ -CA ca.crt -CAkey ca.key \ -CAcreateserial -out sm2_enc.crt \ -days 365 \ -extfile enc_ext.cnf # 同样步骤生成SM2签名密钥对和签名证书 openssl ecparam -genkey -name SM2 -out sm2_sign.key openssl req -new -key sm2_sign.key -out sm2_sign.csr -subj "/CN=web.example.test" openssl x509 -req -in sm2_sign.csr \ -CA ca.crt -CAkey ca.key \ -CAcreateserial -out sm2_sign.crt \ -days 365 \ -extfile sign_ext.cnf

注意，extfile里的扩展项需要区分密钥用法。加密证书要带上keyEncipherment或keyAgreement等用途，签名证书要带上digitalSignature。这两张证书在证书链里的组织顺序、在Nginx里如何配置，后面会讲。很多人在这一步图省事，直接拿同一对SM2密钥生成两张证书，这在严格合规下是有风险的，生产环境不建议这么干。

2.3 证书链拼接与格式转换

国密证书和普通证书一样，需要把站点证书和中间CA证书拼在一起形成完整链，否则客户端会因为找不到签发路径而报错。一个常见的测试环境错误，是直接把站点证书放在ssl_certificate里，中间CA没拼进去，结果是curl勒测失败、浏览器提示“证书不受信任”。

正确做法是将站点证书放在最前面，中间CA依次拼接，生成一个fullchain文件：

cat sm2_enc.crt intermediate_ca.crt root_ca.crt > sm2_enc_chain.crt cat sm2_sign.crt intermediate_ca.crt root_ca.crt > sm2_sign_chain.crt

私钥和证书是分开的，主证书链文件与对应的SM2私钥文件要保持一致。实际排查这种问题最有用的命令是：

openssl s_client -connect localhost:443 -servername web.example.test </dev/null 2>/dev/null | grep "Verify return code"

如果看到unable to get local issuer certificate，基本就是证书链拼接出了问题。

3. Nginx+uWSGI联动部署实录

3.1 国密SSL能力从哪里来：密码库与Nginx构建

Nginx官方原版并不直接支持国密套件，它的ssl模块依赖OpenSSL，而主流的系统OpenSSL默认没有开启国密算法。要让Nginx具备国密能力，需要链接一个支持SM2/SM3/SM4的国密SSL分支。这一环节是整个部署里最需要耐心的一步，因为编译配置错了，后面全白搭。

实际编译时，我习惯用静态编译方式把国密SSL库直接打进Nginx，避免运行时依赖库冲突。操作逻辑是：先拿到国密SSL分支的源码，编译安装到独立目录，再带着这个库的include路径和库路径去编译Nginx。关键编译参数长这样：

./configure \ --prefix=/usr/local/nginx-gm \ --with-http_ssl_module \ --with-http_v2_module \ --with-ssl_module \ --with-openssl=/path/to/gmssl-src \ --with-openssl-opt="enable-ssl-trace enable-ec_nistp_64_gcc_128"

这里最核心的是--with-openssl指向国密SSL分支源码目录。编译Nginx之前，会先自动编译这个SSL库。如果你希望Nginx动态加载系统已有的国密库而不是自己再编译一份，需要确保系统库的版本和Nginx编译时的SSL头文件版本一致，否则ssl_ciphers里的国密套件可能识别不出来。

渲染一下这个选择：为什么不用普通OpenSSL再装个国密补丁？因为补丁方案依赖系统版本匹配，换一次系统升级就很痛苦。把国密SSL分支和Nginx打包编译成一个独立的二进制，部署到哪台机器都是同一套行为，遇到问题也好定位。这就是实测里更省心的做法。

3.2 Nginx服务器配置实战

Nginx的国密HTTPS配置，核心是让它在双证书模式下工作。一个可以跑起来的server块配置我会这么写：

server { listen 443 ssl; server_name web.example.test; # 国密双证书：签名证书 + 加密证书 ssl_certificate /etc/ssl/gm/sm2_enc_chain.crt; ssl_certificate_key /etc/ssl/gm/sm2_enc.key; ssl_certificate /etc/ssl/gm/sm2_sign_chain.crt; ssl_certificate_key /etc/ssl/gm/sm2_sign.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-SM2-SM4-CBC-SM3:ECDHE-SM2-SM4-GCM-SM3:ECDHE-RSA-AES128-GCM-SHA256; ssl_session_cache shared:SSL_GM:10m; ssl_session_timeout 1d; location / { include uwsgi_params; uwsgi_pass 127.0.0.1:8000; # 让后端Python框架感知到原始HTTPS协议 uwsgi_param UWSGI_SCHEME https; proxy_set_header X-Forwarded-Proto https; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

不同国密SSL分支对配置指令的接受程度可能略有差异。比如有的分支要求加密证书在前、签名证书在后，有的分支则相反；有的分支支持同一server块里写两个ssl_certificate，有的分支需要在不同server块里分别处理。现场实测时，先用nginx -t验证配置，再按握手日志调整顺序。

这里有一个容易被忽略的点：ssl_ciphers里的优先级顺序。ECDHE-SM2-SM4-CBC-SM3这种国密套件要放在前面，让支持国密的客户端优先走国密通道。第二部分保留一个国际算法兜底，是为了那些不支持国密的客户端仍然能访问。这不是妥协，而是双证书方案本就应该有的平滑降级能力。

3.3 uWSGI侧配置与Python框架配合

uWSGI这边保持简单。它只需要监听回环地址或unix socket，不启用自己的SSL装饰，让Nginx作为唯一对外出口。一个我惯用的uwsgi.ini配置长这样：

[uwsgi] socket = 127.0.0.1:8000 chdir = /data/www/webapp module = app:app master = true processes = 4 threads = 2 buffer-size = 65535 http-timeout = 60 harakiri = 60 uid = web gid = web vacuum = true die-on-term = true

这个配置里没有ssl相关指令，因为uWSGI不需要对外做TLS终结。它和Nginx之间走的是本地或者内网链路，默认信任这个链路是安全的。如果你出于安全考虑还是希望Nginx到uWSGI这一段也加密，那就失去了“零改造”的本来意义，而且引入的复杂度远大于收益。等保里检查的是外部通信链路的加密性，内网链路在有边界防护的前提下风险可控，运维上只要保证本机回环或内网隔离即可。

Python框架侧需要做的只有一件事：信任Nginx转发过来的HTTPS头部标识。Django里配置一行：

SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")

Flask则加上ProxyFix中间件：

from werkzeug.middleware.proxy_fix import ProxyFix app.wsgi_app = ProxyFix(app.wsgi_app, x_proto=1, x_for=1)

这两个配置的作用是让request.is_secure()正确返回True，否则Django的CSRF校验、Flask里的URL生成、以及各种强制HTTPS跳转逻辑都会出问题。注意，这部分不是业务逻辑改动，而是框架对代理部署环境的常规适配，不影响任何接口的实现。

3.4 PyCryptodome的职责边界与补充国密能力

到这里必须认真澄清PyCryptodome的角色，免得有人照搬标题、误以为它是国密算法的主力。PyCryptodome是一个功能很全的密码学工具库，但SM2、SM3、SM4这几位国密家族的成员，它并不原生支持。那标题里的“PyCryptodome联动”落在哪里？落在应用层的数据保护和密钥管理上。

这套方案上了国密HTTPS之后，测评员还会看业务系统的敏感数据有没有做加密存储、备份里有没有明文密码、日志里有没有泄露Token。这些地方才是PyCryptodome的主场。比如我用它来加密数据库连接串和第三方接口密钥：

from Crypto.Cipher import AES from Crypto.Protocol.KDF import PBKDF2 from Crypto.Random import get_random_bytes salt = get_random_bytes(16) key = PBKDF2("master-password", salt, 32, count=1000000) cipher = AES.new(key, AES.MODE_GCM) ciphertext, tag = cipher.encrypt_and_digest(b"db_password_string")

如果业务数据本身也有国密加密要求，比如某个接口要求对报文字段做SM4加密后再落库，那需要在Python侧单独引入支持国密的算法包，并且和PyCryptodome做接口边界划分。我的建议是：凡是为满足国密测评而要求的加密逻辑，走国密算法库或硬件密码模块，不要试图用PyCryptodome兜底；凡是通用场景的密钥派生、随机数生成、Token签名，继续用PyCryptodome没有问题。理清这个边界，你在做技术答辩时才能说得清楚，测评员也不会抓到你方案里的逻辑漏洞。

4. 部署验证与兼容性实测

4.1 用命令行验证国密握手链路

部署完成后，第一件事是验证对外的确是一条国密链路。如果你使用的国密SSL分支提供了配套客户端工具，直接用它的s_client子命令最直观：

gmssl s_client -connect web.example.test:443 -servername web.example.test \ -cipher ECDHE-SM2-SM4-CBC-SM3 </dev/null

输出里重点看三样东西：握手协议版本是否按预期是TLSv1.2或TLSv1.3；协商出的cipher是否是国密套件；证书链的Verify return code是否为0。如果协商出来的套件是ECDHE-RSA-AES128-GCM-SHA256而不是国密套件，说明客户端没有被强制指定国密算法，或者Nginx的套件优先级排序没生效。

用普通的openssl s_client也可以测，但前提是你的系统OpenSSL版本本身支持SM2套件，否则握手到密钥交换阶段会报错。这也是为什么我前面强调，把支持国密的SSL库和Nginx一起构建，而不是依赖系统自带OpenSSL来做验证。

4.2 常见浏览器的兼容与降级策略

国密HTTPS部署完之后，马上会面临一个现实问题：终端用户浏览器里还装着国际根证书，国密证书在普通浏览器里不一定受信任。政务、金融场景的客户通常有专用浏览器或客户端，这个问题不大；但如果你的系统也要面向普通用户，就必须保留国际证书作为降级通道。

实践里的做法是Nginx在443端口同时挂国密证书和国际证书，通过套件优先级和客户端能力协商来实现自动切换。支持国密的客户端进来，优先协商国密套件；普通浏览器进来，自动落到RSA证书的国际套件。这样一套配置，既满足测评现场“国密优先”的要求，又不影响存量用户正常打开网页。

还有一个细节容易踩坑：页面里如果引用了http协议的外部静态资源，浏览器会拦截并提示“混合内容”，用户看着就像站点没HTTPS一样。这时候要从应用层把资源URL统一改成https://或使用协议相对路径//。这也是为什么零改造不等于不动代码，总要有一两个地方需要配合适配。

4.3 性能基线：握手延迟、会话缓存与长连接

国密算法在CPU密集运算上的开销确实比国际算法高一点，特别是在握手阶段，SM2的密钥交换比ECDHE要多几次大整数运算。实际压测中，无缓存情况下的首次握手比传统RSA握手慢大约20%到40%，但这个差距在开启会话缓存之后会被抹平不少。

Nginx配置里要舍得开ssl_session_cache shared:SSL_GM:10m。10MB共享内存大约能存数万个会话，对一般业务量绰绰有余。同一客户端在会话超时时间内重新连接，可以省掉完整的握手过程，整体延迟表现会很接近普通HTTPS。

压测时注意不要用压测工具默认的短连接模式，因为那会强制每一次都走全套握手，测出来的数字会很难看。更接近真实场景的方式是开启连接复用和会话复用，我习惯用支持HTTP Keep-Alive的压测工具做混合场景测试。性能优化不是要证明国密和RSA一样快，而是要让业务团队意识到，这点开销在合理配置下不会成为瓶颈。

5. 常见问题排查与避坑记录

5.1 配置层面的典型错误

部署过程中我遇到最多的配置问题，第一个就是证书顺序搞反。国密双证书在某些SSL分支里要求先加密证书后签名证书，有的正好相反。判断方法很简单：启动Nginx后用国密客户端握手一次，如果服务端报“no shared cipher”，优先检查证书顺序，而不是去改密码套件列表。

第二个是中间CA缺失。这种情况通常客户端报unable to get local issuer certificate，服务端日志里却一切正常。因为Nginx对客户端能不能构建完整链并不敏感，它只知道把自己的证书链发出去。处理方式就是前面说的，把站点证书和中间CA拼到同一个chain文件里。

第三个是编译时系统里的OpenSSL版本和Nginx实际链接的国密SSL库版本不一致，导致ssl_ciphers里的国密套件名识别失败，Nginx启动直接报错。这种情况用ldd /usr/local/nginx-gm/sbin/nginx看看它实际链接的libssl路径就能发现。如果发现它意外链接到了系统libssl，说明编译时--with-openssl参数没有正确生效。

5.2 应用感知反向代理的坑

前端网关后面挂Python应用，一定会遇到一个经典问题：Django或Flask认为当前请求是HTTP而不是HTTPS，导致重定向和URL生成全部变成http。这不是国密方案的专属问题，但在国密HTTPS改造时最容易爆发，因为大家注意力全放在证书和密码库上，忘了告诉框架“外面已经走完TLS了”。

解决办法上来就写过了，Django配置SECURE_PROXY_SSL_HEADER，Flask挂ProxyFix。但还有一层要注意：这个代理头信任如果随便开启，等于给请求伪造开了后门。本来外部黑客无法直接访问内网，但如果Nginx把X-Forwarded-Proto透传进来，攻击者自己伪造这个头，框架就可能误判为HTTPS而放行某些本应被拦截的逻辑。所以Nginx那一层要对上游过来的头部做好覆盖，比如用proxy_set_header X-Forwarded-Proto $scheme;强制覆盖，不信任客户端传入值。

另外，uWSGI工作目录的权限问题也时常发生。以uid=web gid=web启动uWSGI时，要保证/data/www/webapp目录下文件可读，socket目录可写。否则Nginx和uWSGI之间的unix socket建不起来，表现就是Nginx报502。排查顺序一定是：先看uwsgi进程在不在，再看socket文件有没有权限，最后才去翻应用日志。

5.3 常见问题速查表

我把实际项目中遇到过的、以及同行交流时提到过的高频问题整理成一张速查表，方便你现场排查时快速定位。表格里的命令都是我在真实环境里验证过的方向，不是纸上谈兵。

这张表看着简单，但它对应的每个问题，背后都是一段真实的排障经历。尤其是双证书顺序和证书链拼接，我几乎每次帮别人排查国密接入问题时都会碰到。记住一句话：先验证证书链路，再谈套件协商，最后才查应用逻辑。

我个人在实际操作中的一个体会是，国密HTTPS改造本身没什么高大上的技术门槛，真正考验人的是对链路里每一层职责边界的理解。很多人被“国密”两个字吓住了，一上来就想把所有代码重写一遍。其实只要把SSL终结、证书体系、应用层加密这三件事分开看待，各自找对工具，零改造接入是完全可行的。

最后再分享一个小技巧：整套环境里的Nginx构建脚本、证书签发命令、uWSGI配置和Python侧的中间件适配，全部整理成一套可执行的部署脚本，并把脚本纳入版本管理。这样每一次证书更新、密码库升级、配置调整都有迹可循，测评整改需要提供证明材料时，也能快速回溯当时到底改了什么。运维的事，确定性就是安全感。