JDK 1.8配置DSA 1024后SSL握手失败，求原因排查

咱们一步步拆解这个问题，结合你给出的Java 8环境和操作场景，核心原因都围绕DSA算法在现代SSL/TLS生态中的支持局限性以及Java安全配置对密码套件的影响：

1. 当配置为DSA时 #

这个配置直接禁用了所有DSA相关算法，包括证书的签名算法和对应的SSL密码套件。你的服务器依赖DSA 1024证书提供SSL服务，一旦DSA被全局禁用，服务器端无法加载任何与DSA匹配的密码套件，自然无法和客户端协商出共同可用的加密套件，握手直接失败。

2. 当配置为DSA keySize < 1024时 #

虽然你的证书是合规的1024位，但这里有两个关键问题：

• Java 8对DSA密码套件的支持有限：Java 8中与DSA匹配的密码套件多为TLS_DHE_DSS_WITH_*系列，这类套件在默认配置中启用的数量很少。
• 客户端普遍不再支持DSA套件：现代浏览器（Chrome、Firefox等）和多数HTTP客户端已经移除了对DSA相关密码套件的支持，因为DSA的安全性远不如RSA或椭圆曲线算法（EC）。服务器端只能提供DSA套件，客户端没有对应支持，自然出现"无共同套件"的异常。

3. 当配置为空时 #

你可能以为空配置会取消所有算法限制，但实际有两个坑：

• Java 8u171的jdk.certpath.disabledAlgorithms默认包含DSA keySize < 1024，但设置为空后，虽然移除了这个限制，但客户端不支持DSA套件的问题依然存在——客户端还是没有能和服务器端DSA证书匹配的加密套件。
• 另外，Java的JSSE（安全套接字扩展）在空配置下，可能不会自动启用所有DSA密码套件，导致服务器端实际可用的DSA套件数量为0，进一步加剧了握手失败的概率。

总结 #

三种配置最终都触发同一个异常，本质是DSA 1024证书对应的加密套件已经被现代客户端广泛弃用，再加上Java安全配置的限制，导致服务器和客户端无法协商出共同的加密套件。如果要解决这个问题，建议更换为RSA 2048+或椭圆曲线（EC）证书，这类算法的密码套件在客户端和Java环境中都有良好的支持。

内容的提问来源于stack exchange，提问作者Hhovhann