启用2-way SSL用ECDSA证书时TLS握手在ClientKeyExchange ECDH阶段失败咨询

报错基础解释 #

你日志中输出的加密前明文02 0a是标准TLS告警编码：

• 第一个字节02代表告警级别为致命
• 第二个字节0a代表告警类型为意外消息，即服务端收到了不符合当前握手阶段预期的报文

可能的故障根因 #

• RSA JsafeJCE提供商EC实现兼容性问题：你当前将com.rsa.jsafe.provider.JsafeJCE设为优先级最高的安全提供商，该组件的ECDH密钥协商逻辑和OpenSSL客户端存在已知兼容问题，常见触发场景为服务端配置的EC曲线未被OpenSSL客户端支持、或曲线参数格式不符合JsafeJCE的解析规则，会直接在ClientKeyExchange校验阶段抛出异常触发告警。
• 客户端证书校验异常：双向认证场景下，如果客户端提交的ECDSA证书链存在扩展字段缺失、签名算法与证书公钥曲线不匹配、或未被服务端truststore信任的情况，JsafeJCE的证书校验逻辑会提前终止握手，返回通用的意外消息告警。
• 报文顺序被篡改：即使直接使用openssl s_client本地测试，也要确认是否存在端口转发、本地防火墙规则篡改了握手报文顺序，导致服务端在预期接收CertificateVerify报文的阶段收到了ClientKeyExchange报文，触发顺序异常告警。
• 密钥库配置错误：确认服务端truststore中导入的根证书/中间证书为ECDSA类型，且证书链完整，JsafeJCE对证书链的校验规则比原生JDK更严格，缺失中间证书也会触发该隐晦错误。

更详细错误信息获取方案 #

• 调整JVM debug参数：将原有-Djavax.net.debug=all替换为-Djavax.net.debug=ssl:handshake:verbose:trustmanager:keymanager，过滤冗余的加解密日志，单独输出握手阶段的证书解析、密钥协商参数计算的全量细节，可直接定位具体校验失败的步骤。
• 临时替换安全提供商验证：将JDK安全配置中security.provider.1修改为默认的sun.security.provider.Sun，security.provider.2修改为com.sun.net.ssl.internal.ssl.Provider，切换原生JDK安全实现测试，如果握手成功即可确认是JsafeJCE的兼容问题，后续可针对性调整JsafeJCE的EC参数白名单配置。
• 抓包验证报文合法性：用tcpdump/Wireshark抓取完整的TLS握手报文，对比ClientHello中客户端声明支持的EC曲线列表、ServerHello中服务端选择的曲线、以及ClientKeyExchange报文中的EC公钥长度是否符合预期，可直接定位参数不匹配的问题。

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