JDK17使用TLS v1.2连接内部设备时握手失败：EC密钥无支持的CertificateVerify签名算法

看起来你遇到的是JDK 17在TLS 1.2握手时，EC密钥签名算法匹配的兼容性问题，我来帮你拆解下~

首先说核心矛盾：你的证书用的是secp256r1（也就是常说的P-256）椭圆曲线，但TLS握手协商出来的签名算法却是ecdsa_secp384r1_sha384——这个签名算法是和secp384r1（P-384）曲线绑定死的，和你证书的secp256r1完全不匹配。JDK的SSL层在这块校验得特别严格，会直接拒绝这种跨曲线的组合，这就是你日志里看到“unsupported EC parameter spec: secp256r1”的原因。

至于为什么OpenSSL能用同一份证书密钥成功连接？这是因为OpenSSL的处理逻辑更灵活，它会忽略签名算法里绑定的曲线信息，直接用证书实际的EC密钥来做签名验证，只要哈希算法（这里是SHA-384）和密钥兼容就没问题。但JDK的实现严格遵循了TLS 1.2规范里的签名算法绑定逻辑，在SignatureScheme类里做了硬校验，不允许这种跨曲线的操作。

这并不是JDK“没实现”相关功能，而是JDK对TLS签名算法的校验逻辑比OpenSSL更严谨，大概率是下面两个原因导致的：

• 你的内部设备TLS配置有问题：它在握手时把ecdsa_secp384r1_sha384放到了签名算法列表的最前面，却没优先列出和你证书匹配的ecdsa_secp256r1_sha256（或者ecdsa_secp256r1_sha384）。
• JDK端的默认签名算法列表里，和secp256r1匹配的算法优先级太低，甚至被排除了，导致协商时选到了不匹配的选项。

给你几个可行的解决方向： #

1. 强制指定JDK的签名算法优先级
   你可以通过JVM启动参数，强制让JDK优先使用和secp256r1匹配的签名算法，比如在启动程序时加上：

   -Djdk.tls.client.protocols=TLSv1.2
   -Djdk.tls.signatureSchemes=ecdsa_secp256r1_sha256,ecdsa_secp256r1_sha384,rsa_pkcs1_sha256
   

   这样能确保握手时优先选到和证书曲线匹配的算法，避免跨曲线的问题。

2. 调整内部设备的TLS配置
   如果有权限修改设备的TLS设置，建议把ecdsa_secp256r1_sha256或ecdsa_secp256r1_sha384放到签名算法列表的最前面，让设备优先协商和客户端证书匹配的算法。

3. 自定义SSLContext过滤签名算法（进阶）
   如果上面两个方案都没法实施，你也可以在代码里自定义SSLContext，手动过滤掉不兼容的签名算法，只保留和secp256r1匹配的选项。不过这种方式需要修改代码，相对麻烦一些。

备注：内容来源于stack exchange，提问作者Jérémie B