嘿，你的思路是对的，修改java.security里的jdk.tls.disabledAlgorithms配置确实是修复这个弱密钥交换漏洞的核心步骤，但确实有些情况下只改这一行还不够，我来给你梳理几个需要额外检查的点，确保漏洞彻底解决：

• 确认你修改了正确的配置文件：不同Java环境的java.security位置可能不一样——比如如果你的应用部署在Tomcat、JBoss这类容器里，它们可能自带了独立的JRE，此时你需要修改容器内置JRE中的java.security，而不是系统默认JDK的配置文件。可以通过应用日志或者执行java -XshowSettings:properties查看java.home路径，找到对应的配置文件位置。

• 检查是否存在硬编码的DH参数：有些应用或服务器（比如Tomcat）会在SSL配置中直接指定DH参数文件（比如在server.xml的<Connector>标签里配置ciphers或者dhParameterFile）。如果这个参数文件里的DH密钥长度小于2048位，就算全局配置禁用了弱DH，应用还是会使用这些硬编码的参数。你需要生成新的2048位DH参数：

  openssl dhparam -out dhparams.pem 2048
  

  然后在服务器配置中引用这个新文件，替换旧的参数。

• 排查应用是否重载了TLS配置：部分Java应用会通过代码自定义SSLContext，这种情况下可能会绕过java.security的全局配置，直接启用弱DH套件。你需要检查代码中关于SSL/TLS配置的部分，确保没有显式启用密钥长度小于2048位的DH算法。

• 验证配置修改是否生效：修改完配置后一定要重启应用服务，然后用工具验证弱DH套件是否被禁用。比如用OpenSSL命令测试：

  openssl s_client -connect your-domain:443 -cipher "DHE"
  

  查看返回结果中的“Server Temp Key”部分，确认DH密钥长度至少为2048位；或者用nmap --script ssl-enum-ciphers -p 443 your-domain扫描，检查是否还有弱DH套件被列出。

• 确认ECDH配置无遗漏：你的配置里已经设置了EC keySize < 224，这符合要求，但可以额外确认jdk.disabled.namedCurves是否包含了所有弱椭圆曲线（比如secp192r1这类），确保ECDH部分也没有安全隐患。

总的来说，修改jdk.tls.disabledAlgorithms是基础操作，但结合上面这些检查点，才能彻底解决弱密钥交换的漏洞，避免后续扫描还出现告警。

备注：内容来源于stack exchange，提问作者cekodis681 cekodis681