企业官网建设流程全解析

扫描报告甩过来的时候，一屏的CVE-2016-2183，端口从 443 排到 8443，底下跟一行小字"SSL/TLS协议信息泄露漏洞"。这种工单在 Linux 运维的日常里太常见了，而且它有个很烦人的特点：不适配、不崩溃、不影响业务，但扫描器就是盯着不放，甲方或安全部门就是要求整改闭环。

这个漏洞在圈子里更常被叫SWEET32，本质是 3DES 这类 64 位分组密码在 CBC 模式下扛不住生日攻击。处理它的路子不止一条：既可以在 Nginx、Tomcat、sshd 的配置层把 3DES 套件直接摘掉，也可以老老实实升级 openssl。前者十分钟能搞定但依赖当前库版本支持，后者看起来一劳永逸，实际上一脚踩空就是 ssh 连不上、yum 报错、系统命令集体失灵。这篇就把我在 Linux 上处理这个漏洞的完整链路摊开讲——怎么判断该走哪条路、升级 openssl 时哪些参数不能乱改、以及复扫结果对不上时该从哪几个方向查。

1. SWEET32 到底在打什么：把 64 位分组密码的原理摊开看

1.1 生日悖论怎么就从数学题变成了"信息泄露"

先说清楚攻击的立足点。CBC 模式下的分组密码，每个密文分组的长度等于分组长度。3DES 的分组长度是 64 位，也就是 8 字节。当你在同一条加密连接上发送了足够多的数据之后，根据生日悖论，出现两个完全相同的密文分组的概率会快速上升——大概在发送 2 的 32 次方块之后（也就是约 32 GiB 数据），碰撞概率就到 50% 左右。

生日悖论其实不玄乎：一个教室里只要有 23 个人，就有超过一半的概率存在两个人生日相同。分组密码的"生日"就是那 8 字节的取值空间，只有 2 的 64 次方种可能，撞车比人想象的容易得多。

碰撞一旦发生，攻击者就能拿到两个明文分组的异或值。这时候如果其中一个明文是可猜测的或者已知的（比如浏览器重复发送的 Cookie、HTTP 头里的固定字段、报文里的已知结构），异或值一减，另一个未知明文就暴露了。这就是所谓"明文恢复"。

1.2 为什么扫描器只揪着 3DES，不揪 AES

看一个对比就明白了：

关键点在于：3DES 的密钥强度是够的（112 位有效密钥，暴力破解不现实），但它的分组长度只有 64 位，短板在分组上而不在密钥上。也就是说，3DES 的安全性被钉死在大约 32 位量级，跟密钥多长没关系。

SWEET32 论文里展示真实攻击时，抓了大约 785 GB 的流量才把一条会话里的认证凭据还原出来。785 GB 听起来很多，但在一条长时间不断流的大流量长连接上，比如视频流、大文件持续下载、保持长连的 API 网关，是能攒出来的。所以它被定为可利用的缺陷，NVD 给出的 CVSS 3.x 评分是 7.5，级别高危。

提示：这个 CVE 不只影响 TLS。原文明确覆盖 TLS、SSH、IPSec 等使用 64 位 CBC 分组的协议。很多人只改了 443，扫描器照样报，问题出在 22 端口的3des-cbc没动。

1.3 三条修复路径的取舍，我用一张表说清楚

遇到这个漏洞，实际能走的路就三条，成本差别很大：

我的经验是：先试第一条，撑不住再上第二条。因为第一条改的是配置，随时可以改回来；第二条改的是运行时底座，改错了整台机器都可能进不去。而且很多场景下配置层封堵本来就是合规可接受的整改方式——扫描器扫的是"服务端是否还会协商出 3DES"，只要协商不出来，扫描就过了。

2. 动手之前先摸家底：三件必须先确认的事

2.1 系统自带的 openssl 是哪个版本，被谁依赖

上来就yum update openssl或者下载源码覆盖安装，是最容易出事的做法。先看版本：

openssl version -a rpm -qa | grep -i openssl rpm -q --whatrequires openssl-libs | wc -l

最后那条命令很关键。在 CentOS/RHEL 系上，openssl-libs被几百个包依赖，sshd、yum、curl、rpm、postfix、python里的ssl模块都挂在它上面。它不是一个可以随便替换的独立组件，而是系统底座的一部分。

不同发行版自带的版本差异也很大，这个差异直接决定你能不能用配置层解决问题：

• CentOS 7 / RHEL 7：openssl 1.0.2k，默认 cipher 列表里还带 3DES，配置层禁用有效但需要手工写。
• CentOS 8 / Rocky 8 / Alma 8：openssl 1.1.1，默认已经不含 3DES，通常扫描器不会再报。
• Ubuntu 20.04：openssl 1.1.1f，情况类似。
• Ubuntu 22.04 / Debian 12：openssl 3.0.x，安全等级机制更严格，3DES 基本默认不可用。

所以，如果是 CentOS 7 这类老系统，你面对的往往不只是 3DES 一个问题，TLS 1.0、RC4、SHA1 证书签名大概率会一起被扫出来。

2.2 到底哪个服务在协商 3DES

不要只盯着报告里的 443。先把监听端口列出来：

ss -lntp

然后把每个和加密相关的服务都过一遍：Nginx、Apache、Tomcat、Java 应用、Redis TLS、MySQL TLS、PostgreSQL、还有容易被忘掉的 22 端口 SSH。我见过最典型的漏项就是：把 Nginx 的 cipher 列表清得干干净净，扫描器还在报——因为报的是同一个 IP 的 22 端口。

如果是 Nginx，用nginx -T | grep -i ssl能把加载的完整配置打出来，比翻文件快得多，也能顺便发现某个server块里单独写过ssl_ciphers，把全局配置给覆盖了。

2.3 判断这台机器能不能承受"覆盖式升级"

我给自己的判断清单是四条，任何一条不满足，就坚决走并行安装而不是覆盖：

• 这是不是生产核心节点，能不能接受 30 分钟以上的停机窗口？
• 有没有虚拟机快照或者系统级备份可以回滚？
• 机器上有没有跑着依赖系统 openssl 的自研程序（这类程序链接的是哪个 soname）？
• 有没有 yum/apt 在线源可用，还是完全离线的内网环境？

提示：内网离线机器要提前准备源码包和依赖 RPM。等到了现场才发现缺zlib-devel、缺perl-core，只能来回折腾，浪费时间还容易出错。

3. 配置层封堵：不碰系统库也能把 3DES 摘干净

3.1 Nginx 和 Apache 的 cipher 列表怎么写

Nginx 的核心是ssl_ciphers指令，语法是 OpenSSL 的 cipher string，支持!取反排除。一个我常用的写法：

ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers on; ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!RC4:!MD5:!PSK:!SRP:!DSS';

几个要点解释一下：!DES和!3DES是这次的主角，两个都写是为了防止某些写法下DES匹配不到DES-CBC3-SHA；!RC4和!MD5顺手解决另外两个常被扫出来的问题；!aNULL排除匿名套件，!EXPORT排除出口级弱算法。ssl_prefer_server_ciphers on让服务端决定套件优先级，避免客户端强行把弱套件抬上来。

Apache 写法定类似，但它默认用冒号分隔，并且要显式开启服务端优先：

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite HIGH:!aNULL:!MD5:!3DES:!DES:!RC4:!DHE SSLHonorCipherOrder on

我建议顺手把 TLS 1.0 和 1.1 也关掉。理由很直接：3DES 在 TLS 1.2 里本来就不该被协商，而 TLS 1.0/1.1 恰恰是很多扫描器把 3DES 报出来的"温床"。关掉老协议，一套整改就把两个待办合并了。

3.2 Tomcat 和 Java 应用侧的处理

Java 这条路走的是 JVM 层面的黑名单。JDK 8u161 及之后的版本，jdk.tls.disabledAlgorithms里已经默认包含了3DES_EDE_CBC，所以如果 JDK 够新，什么都不用做。但如果是 8u151 之前的版本，就得手工往$JAVA_HOME/jre/lib/security/java.security里加：

jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL

改完所有用到这个 JDK 的 JVM 都要重启才生效。Tomcat 自己在conf/server.xml的 Connector 上还能再加一层保险：

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="150" SSLEnabled="true"> <SSLHostConfig> <Certificate certificateKeystoreFile="conf/keystore.jks" type="RSA"/> <Ciphers cipher="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"/> </SSLHostConfig> </Connector>

注意这里是白名单写法，只有列出来的套件可用，比黑名单更保险。

3.3 SSH 的 3des-cbc 是最常被漏掉的一项

这一项单独拎出来说，因为它实在太容易被忽略。OpenSSH 在较老的版本里默认体系里包含3des-cbc，扫描器扫 22 端口就会命中同一个 CVE。处理方式是编辑/etc/ssh/sshd_config：

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com MACs hmac-sha2-256,hmac-sha2-512,umac-128@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com KexAlgorithms curve25519-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,diffie-hellman-group-exchange-sha256

改完之后，不要直接systemctl restart sshd就把当前会话断开。正确做法是先开一个空闲的新窗口留着不关，在这个新窗口里执行sshd -t检查语法，语法通过之后 reload 或者 restart，然后另开一个窗口验证能不能登录成功。全部确认没问题，再关掉那个保底窗口。这个习惯能救你很多次——尤其在不能带外管理、只能靠 SSH 进去的机器上。

禁掉3des-cbc的副作用也要提前想好：一些老旧的交换机、防火墙管理口、工业控制终端、银行前置的老客户端，可能只支持 3des-cbc。如果你的环境里有这类设备，禁用之后它们就连不上了，这个必须提前登记清楚再动手。

4. 真要升级 OpenSSL：编译、装载与本地验证

4.1 源码编译的参数该怎么定

假设系统库太老、配置层走不通，那就得自己编译一份。我固定用下面这套参数：

tar -zxvf openssl-1.1.1w.tar.gz cd openssl-1.1.1w ./config --prefix=/usr/local/openssl --openssldir=/usr/local/openssl shared zlib make -j$(nproc) make test make install

逐个参数解释，因为这里改错一个后面会很麻烦：

--prefix=/usr/local/openssl决定了安装根目录。我坚持放在/usr/local下面而不是直接覆盖/usr，就是为了和系统自带的库物理隔离。这么做之后，系统自带的libssl.so.10原封不动躺在/usr/lib64，新装的libssl.so.1.1在/usr/local/openssl/lib，谁也不碰谁。

--openssldir指的是证书和配置文件目录。两者设成一样是为了少踩坑，有些老程序读配置时会去找openssl.cnf，路径分叉了就是一个"文件找不到"的报错。

shared生成动态库。必须加，否则只会出静态库libssl.a，Nginx 这类需要动态链接的程序就没办法用。

zlib启用压缩支持。不加的话，某些依赖压缩的握手场景会有兼容问题。

make test不要省。它会跑一遍自带的测试用例，能在安装之前就发现"这个平台的编译器有问题"或者"架构不匹配"之类的硬伤。ARM 平台、国产 CPU 平台上跑一遍测试尤其必要。

4.2 让程序真正用上新库：链接路径的三种做法

装完不等于生效。系统里可能同时存在三份 openssl，which openssl找到哪个完全取决于 PATH 顺序。这时候要让目标程序明确链接到新库，常见三种做法：

第一种，编译时打 rpath。在编译 Nginx 或者自研程序时，把库路径直接写进二进制：

./configure --prefix=/usr/local/nginx \ --with-openssl=/usr/local/src/openssl-1.1.1w \ --with-openssl-opt=shared \ --with-http_ssl_module make && make install

--with-openssl指向源码目录时，Nginx 会把这份 openssl 一起编进自己的二进制里，最终产物不再依赖系统库。这是我处理 Nginx 时最推荐的方式，干净、彻底、不受其他因素干扰。

第二种，LD_LIBRARY_PATH临时指定。只适合调试和验证，绝不要写进生产环境。它只对当前进程和子进程有效，systemd 拉起来的服务根本读不到这个变量，而且它会影响所有子进程，出了诡异问题很难定位。

第三种，ld.so.conf.d+ldconfig。往/etc/ld.so.conf.d/openssl.conf里写一行/usr/local/openssl/lib，然后ldconfig。这种方式影响面是全局的，但因为新库的 soname 是libssl.so.1.1而系统的是libssl.so.10，两者不冲突，动态链接器会按 soname 精确匹配，一般不会串。不过还是建议执行之后用ldconfig -p | grep libssl确认一下结果，看看有没有出现意料之外的库版本。

提示：systemd 管理的服务可以用Environment="LD_LIBRARY_PATH=/usr/local/openssl/lib"单独指定库路径，比全局ldconfig更克制的做法，适合只想让某个服务用新库的场景。

验证的时候别偷懒，用绝对路径：

/usr/local/openssl/bin/openssl version -a ldd /usr/local/nginx/sbin/nginx | grep ssl

ldd那行输出会告诉你 Nginx 到底链接到哪一份库。如果显示的还是/usr/lib64/libssl.so.10，说明你的--with-openssl没生效，得回头检查编译参数。

4.3 升级完成后必须补上的四件事

装完库、编译完 Nginx 只是完成了百分之七十。剩下的收尾工作少一件都可能让复扫结果对不上：

第一，跑ldconfig刷新动态链接器缓存，否则新装的库可能压根没被识别。

第二，把所有链接了 ssl 的自研程序重新编译一遍。源码编译的程序在链接那一刻就把要用的符号定下来了，库升级之后不重编，很容易出现符号找不到或者行为不一致。

第三，验证证书相关的操作还正常。包括证书链校验、私钥读取、p12 转换，尤其是原来用 3DES 加密的私钥文件——虽然 3DES 加解密功能本身还在，但格式解析路径可能有变化。

第四，逐个重启或者 reload 服务，然后复扫。nginx -s reload之后新 worker 才会加载新配置和新库，老 worker 会等到连接处理完才退出，所以复扫要等一两分钟再执行。

5. 升级现场最容易翻车的几个瞬间

5.1 编译阶段卡在依赖和工具链上

编译报错的形态五花八门，但九成集中在三类。第一类是缺头文件，典型报错是zlib.h: No such file or directory，装zlib-devel就好。第二类是 perl 相关，OpenSSL 的构建系统重度依赖 perl 脚本，缺perl-core或者 perl 版本太老（低于 5.10）会在 configure 阶段直接挂掉。第三类是编译器版本，用很老的 gcc 编译 OpenSSL 3.x 会报一堆语法错误，这种情况要么升级 gcc，要么退回到 1.1.1 系列。

离线环境要提前准备的包大致是这些：

# RHEL/CentOS 系 yum install -y gcc gcc-c++ make perl perl-core zlib-devel # Debian/Ubuntu 系 apt install -y build-essential perl zlib1g-dev

5.2 覆盖libssl.so.10之后，系统命令集体失灵

这一条是我见血最多的地方，必须重点说。有人在老系统上按教程把源码编译出来的库直接cp到/usr/lib64/覆盖了原有的文件，然后：

ssh: symbol lookup error: /lib64/libcrypto.so.10: undefined symbol: ... yum: error while loading shared libraries rpm: relocation error

典型症状是ssh、yum、rpm、curl、sudo这些基础命令同时报动态库错误。根因就两个：一是 soname 不匹配，新的libssl.so.1.1顶替了旧程序要找的libssl.so.10，符号对不上；二是 ABI 不兼容，1.0.2 和 1.1.1 之间的结构体布局有变化，即使符号名字对得上也会崩。

真踩进去了怎么救？如果是虚拟机，直接回滚快照最快。没有快照的话，需要从同版本的另外一台机器上把/usr/lib64/libssl.so.10和libcrypto.so.10拷回来（用 scp 不行，因为 ssh 已经坏了，得用 U 盘或者救援模式）。如果这两个文件是被 RPM 包管理的，用救援模式挂载系统后执行重装：

rpm -Uvh --replacepkgs --nodeps openssl-libs-1.0.2k-*.rpm

正因为这个坑的修复成本极高，我才坚持并行安装到/usr/local/openssl，物理上不碰系统库。多花十分钟配置编译参数，省下的是半夜救火的几个小时。

5.3 证书和私钥处理时的格式坑

升级到 OpenSSL 3.0 之后，有几个操作会突然报错，第一次遇到会懵。

最典型的是读旧版 PKCS#12 文件：

# 在 3.0 下直接这么执行，可能报错说算法不支持 openssl pkcs12 -in old.p12 -nodes -out new.pem # 需要显式加载 legacy provider openssl pkcs12 -in old.p12 -nodes -out new.pem -legacy

原因是 OpenSSL 3.0 的 PKCS#12 默认用 AES-256-CBC 加密，而读取用 RC2 等老算法加密的历史文件时，那些算法被挪到了独立的 legacy provider 里，不显式加载就找不到。

另一个是证书链校验报unable to get local issuer certificate。这不是加密算法的问题，而是 CA 证书链不完整或者顺序错了。PEM 格式的证书链文件里，顺序必须是从服务器证书开始，接着是中间证书，最后才是根证书。顺序颠倒会直接导致部分客户端握手失败，而这个错误在服务端日志里往往只能看到一句含糊的握手失败，不好定位。

还有一类是无密码私钥和有密码私钥的转换：

# 加密私钥转成无密码（Nginx 之类要读无密码的） openssl rsa -in enc.key -out plain.key # 反过来，给私钥加密码 openssl rsa -aes256 -in plain.key -out enc.key

提示：转换私钥之前一定先备份原文件。曾经有人把加密私钥转成明文私钥之后顺手删了原文件，结果业务侧程序需要带密码的私钥，只能重新申请证书。

5.4 回滚方案要在动手之前就写好

升级 openssl 之前，我的习惯是先准备三样东西：虚拟机快照或系统备份；原库文件的副本（/usr/lib64/libssl.so.*和libcrypto.so.*）；原版本的 RPM 包或源码包，存在本地目录里。

回滚步骤也要提前写在文档上，而不是临时想：

# 1. 记录当前 rpm 版本 rpm -qa | grep openssl > /root/openssl_versions_before.txt # 2. 备份原库 cp -a /usr/lib64/libssl.so.* /root/backup/ cp -a /usr/lib64/libcrypto.so.* /root/backup/ # 3. 出问题时，用救援模式或单用户模式恢复 cp -a /root/backup/libssl.so.* /usr/lib64/ cp -a /root/backup/libcrypto.so.* /usr/lib64/ ldconfig

这份文档平时看起来是多余的，出事的时候它就是救命稻草。

6. 复扫对不上：验证与排查链路

6.1 用命令行亲测，先确认到底谁还在提供 3DES

不要等扫描器，自己先测。三条命令基本能定位问题：

# 测 TLS：指定只允许 3DES，如果握手成功说明还在协商 openssl s_client -connect 10.0.0.10:443 -tls1_2 -cipher 'DES-CBC3-SHA' # 更全面，直接枚举所有套件 nmap -p 443 --script ssl-enum-ciphers 10.0.0.10 # 测 SSH nmap -p 22 --script ssh2-enum-algos 10.0.0.10

第一条命令如果返回no ciphers available或者handshake failure，说明服务端已经不再提供这个套件，整改到位。如果它正常握手并打印出了证书信息，说明 3DES 还在。第二条命令的输出会按加密强度分组列出来，找有没有3DES字样最快。

6.2 扫描结果对不上的六个常见原因

改完配置复扫还是报，别急着怀疑配置写错了，先按这个顺序排查：

我遇到最多的是第二条和第三条。尤其是 DNS 轮询，负载均衡后面挂着三台机器，只修了一台，扫描器每次解析到的 IP 不一样，结果就是"时好时坏"，很容易误判成配置没生效。

6.3 3DES 之外还会被点名的几项，一次性处理掉

处理 3DES 的时候顺手看一眼报告，这几项通常是一起出现的，一起改比来回扫省事：

• TLS 1.0 / 1.1 支持：直接关掉，只留 1.2 和 1.3。前提是确认没有只支持老协议的老客户端。
• RC4 套件：在 cipher 列表里加!RC4。
• 证书 SHA1 签名：需要重新签发证书，周期长，建议提前排期。
• SSH 的 hmac-md5 / hmac-sha1：在sshd_config的MACs里排除。
• DH 参数小于 2048 位：重新生成 DH 参数文件openssl dhparam -out dhparam.pem 2048，这个生成过程很慢，2048 位在低配机器上可能要跑十几分钟，别以为是卡死了。

提示：openssl dhparam生成 DH 参数时可以加-dsaparam提速，代价是灵活度略降。对大部分场景够用，我在测试环境常用这个技巧。

7. 特殊环境的处理：国产化平台、容器与混合环境

7.1 国产化操作系统上别急着源码覆盖

在银河麒麟、统信 UOS 这类国产化平台上，我的第一原则是优先走官方源。这些系统自带 openssl 大多已经是 1.1.1 系列，或者发行方已经针对这类漏洞打过补丁，包版本号看起来没变但代码里已经改过。先执行yum update openssl openssl-libs或者apt update && apt upgrade openssl libssl1.1，很多情况下扫描就过了。

如果官方源确实没得升，再考虑源码编译，但依然要装到/usr/local下，不要覆盖系统库。国产化平台上还有一个额外注意点：部分系统的包管理器对文件校验比较严格，如果你手工替换了被 RPM 管理的文件，后续yum update会直接报冲突，得先rpm -Va找出被改动的文件再逐个处理。这类平台的架构也更多样，ARM64、MIPS、LoongArch 都有，编译前确认一下 gcc 和 make 在该架构上能不能正常工作。

7.2 容器镜像里的 openssl 不要进容器手改

镜像里改文件是没意义的，容器重建就丢了。正确做法是在 Dockerfile 层面处理：

FROM ubuntu:20.04 RUN apt-get update && \ apt-get install -y --no-install-recommends openssl libssl1.1 && \ rm -rf /var/lib/apt/lists/*

如果基础镜像本身带的就是老版本且源里升不上去，那就得换基础镜像，或者自己基于openssl源码编一个新镜像。涉及到scratch之类的极简基础镜像，替换动态库时要特别小心，因为里面没有包管理器，出问题只能靠重新构建。

还有一个容易忽略的点：有些项目用的是 multistage build，编译阶段用了一个带老 openssl 的构建镜像，虽然运行阶段是新镜像，但编译阶段生成的二进制可能带着老库的链接信息。检查方式是构建完之后在运行镜像里执行ldd看一眼实际链接情况，别只看 Dockerfile 就下结论。

7.3 Windows 侧和"动不了"的老业务怎么处理

混合环境里，Windows 服务器同样会被扫出这个漏洞，但处理方式完全不同，走的是注册表。位置在HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002下面的Functions值，把里面的TLS_RSA_WITH_3DES_EDE_CBC_SHA条目删掉，然后重启生效。改注册表前一定要导出备份，这个键删错了会影响整个系统的 TLS 协商。

至于那些"动不了"的老业务系统——比如只能在特定老版本环境下跑、上游厂商已经停止支持的设备——我的处理经验是做隔离而不是做降级。具体做法是给这些设备单独开一个内部入口，只允许指定的源 IP 访问，外面套一层访问控制和网络层面的限制，不要把整个站点的 cipher 列表都放宽。整站放宽等于为了两三个老设备牺牲所有用户的连接安全性，这个交易不划算。

到最后再分享一个小技巧：改完这些配置之后，除了用 nmap 和 s_client 自测，还可以拿几个真实的客户端做一次冒烟测试——老版本的 Java 客户端、系统自带的 curl、手机浏览器各来一次。因为扫描器只关心套件列表，而真实客户端关心的是握手能不能成功。我踩过一次坑，配置改完扫描全绿，结果某个内部系统用的老 Java 客户端连不上，因为它的密码套件列表里只剩 3DES。扫描器和真实业务，这两件事得分开验证。