Java 8u291后升级至JDK 17/21时，java.security中jdk.tls.disabledAlgorithms默认禁用TLSv1、TLSv1.1及部分弱算法，若配置过度收紧（如误禁EC KeySize
检查 java.security 中禁用的算法是否过度收紧
OpenJDK 升级（尤其是从 8u291 前到 17/21）后，jdk.tls.disabledAlgorithms 默认策略会主动禁用 TLSv1、TLSv1.1 和部分弱密钥交换算法。若服务端只支持 TLSv1.2 但客户端因策略误禁了关键组件（如 EC KeySize ），就会报 SSLHandshakeException: No appropriate protocol。
实操建议：
- 打开
/usr/lib/jvm/jre/conf/security/java.security（Linux）或${JAVA_HOME}/conf/security/java.security（通用路径） - 搜索
jdk.tls.disabledAlgorithms，临时注释整行或删掉TLSv1、TLSv1.1（注意：不是禁用 TLSv1.2） - 重启应用，用
openssl s_client -tls1_2 -connect host:port确认服务端确实支持 TLSv1.2 - 切勿直接删除整个配置项——它还管控 DH 密钥长度、RSA 密钥强度等，删错会导致更隐蔽的
Could not generate DH keypair
确认 cacerts 信任库是否包含目标证书的根 CA
Java 不读系统证书存储，只信任 $JAVA_HOME/lib/security/cacerts。OpenJDK 升级常重置该文件为默认内容，导致旧项目访问自签名或私有 CA 签发的 HTTPS 服务时抛 PkixPathBuilderException。
实操建议：
- 用
keytool -list -cacerts | grep -i "CN=your-ca"检查目标 CA 是否在列表中 - 若缺失，执行
keytool -importcert -alias your-ca -file ca.crt -keystore $JAVA_HOME/lib/security/cacerts（默认口令changeit） - 注意：升级 OpenJDK 后，
cacerts文件可能被覆盖，但旧版本备份通常保留在$JAVA_HOME/lib/security/cacerts.old或同目录下带时间戳的副本中 - 避免用
-trustcacerts参数绕过验证——这只是掩盖问题，不解决信任链断裂
验证 jdk.crypto.ec 模块是否加载成功
OpenJDK 11+ 默认启用模块化，jdk.crypto.ec 提供椭圆曲线加解密支持。若构建运行时未显式包含该模块（如使用 jlink 定制 JRE），HTTPS 握手会在 ECDHE 密钥交换阶段失败，报 ProviderException: Could not derive key 或空指针异常。
实操建议：
- 运行
java --list-modules | grep crypto，确认输出含jdk.crypto.ec - 若缺失，启动参数加
--add-modules jdk.crypto.ec；或重新构建 JRE 时加入--add-modules jdk.crypto.ec - 某些发行版（如早期 Amazon Corretto 11）默认不打包该模块，需单独安装
corretto-11-crypto包 - 不要依赖 BouncyCastle 替代——除非明确禁用所有内置提供者，否则它不会自动接管 EC 运算
排查 OpenSSL 动态库与 Java 的 JNI 层兼容性
当 OpenJDK 使用本地 OpenSSL（而非纯 Java 实现）加速 TLS，比如通过 sun.security.ssl.SSLContextImpl 调用 libssl.so，升级系统 OpenSSL 后可能出现 UnsatisfiedLinkError 或握手卡死。这种情况多见于 OpenJDK 构建时启用了 --with-native-openssl，且未同步更新 JNI 绑定。
实操建议：
- 检查 JVM 启动日志是否有
Loaded OpenSSL version类似提示；无则说明走纯 Java 路径，可跳过本节 - 执行
ldd $(readlink -f $(which java)) | grep ssl，确认链接的libssl路径与当前openssl version -a显示的OPENSSLDIR一致 - 若路径不一致，设置
LD_LIBRARY_PATH=/usr/local/ssl/lib:$LD_LIBRARY_PATH后重试，或降级 OpenSSL 至 JDK 编译时版本 - 最稳妥方式：改用不依赖本地 OpenSSL 的发行版，如 Microsoft Build of OpenJDK 或 Eclipse Temurin，它们默认禁用 native OpenSSL
OpenJDK 升级后的 HTTPS 失败，真正棘手的往往不是配置项本身，而是多个层叠约束同时生效——比如 cacerts 缺失 + disabledAlgorithms 过严 + jdk.crypto.ec 未加载，三者叠加会让错误日志指向最表层的那个（通常是证书验证失败），而实际根因藏在最底下。动手前先用 openssl s_client 独立验证服务端能力，再逐层比对 Java 运行时环境，比盲目调参高效得多。
