Spring Boot升级后Bouncy Castle报错及HTTP头差异问题

1. SSL握手报错根因判定 #

HTTP请求头格式变化和SSL握手报错没有任何关联，完全可以排除这个诱因，核心依据如下：

• 从网络协议栈执行顺序看，SSL握手发生在TCP连接建立完成后、HTTP协议报文（含请求头）传输前，握手阶段还未进入HTTP请求头的构造、处理逻辑，请求头的日志打印格式属于上层应用的展示逻辑，不可能干扰底层TLS握手流程。你观察到的格式差异，只是Spring 5.2.x修改了HttpHeaders类的toString()方法返回值，仅影响日志打印效果，实际构造、发送的HTTP请求头键值对和升级前完全一致。
• 报错java.security.InvalidKeyException: cannot identify XDH private key的真实根因是Bouncy Castle版本兼容问题：
  • Spring Boot 2.6.x默认启用TLS 1.3协议支持，TLS 1.3握手阶段默认优先使用X25519/X448（即XDH系列）椭圆曲线做密钥交换，这类算法是JDK 11+内置SunEC安全提供者原生支持的。
  • Bouncy Castle 1.68版本存在实现缺陷：如果项目中将BC安全提供者注册到了JCE提供者列表的最高优先级，SSL握手时会优先调用BC的密钥解析逻辑，但1.68版本未完整实现XDH私钥的识别能力，直接抛出该异常。
    修复方式可选任意一种：
  • 将Bouncy Castle升级至1.70及以上版本（官方已在该版本修复XDH私钥识别问题，是最推荐的方案）
  • 调整JCE安全提供者加载顺序，将JDK内置的SunEC提供者放在Bouncy Castle之前
  • 临时在TLS配置中禁用XDH相关密钥套件（不推荐，会降低通信安全性）

2. 恢复旧版HTTP请求头打印格式的方案 #

Spring 5.2.x版本重写了HttpHeaders的toString()逻辑，从旧版复用LinkedHashMap的{key=[value1,value2]}格式，改为自定义的[key:"value1", key:"value2"]格式。要恢复旧版打印样式无需修改框架源码，按以下方式处理即可：

• 如果你是在自定义拦截器、日志切面中手动打印请求头，不要直接输出HttpHeaders实例，先将其转换为LinkedMultiValueMap实例再打印，输出结果和旧版完全一致，Kotlin示例代码如下：

// 旧代码（输出新格式）
// logger.info("@RequestHeaders={}", requestHeaders)

// 替换为以下代码
val printableHeaders = LinkedMultiValueMap(requestHeaders)
logger.info("@RequestHeaders={}", printableHeaders)

• 如果你使用Spring内置的请求日志组件（如CommonsRequestLoggingFilter、WebClient默认请求日志），可以自定义日志格式化器，遍历HttpHeaders的entrySet手动拼接字符串：整体用大括号包裹，每个请求头的多值列表用中括号包裹，键值对之间用英文逗号分隔即可，和旧版输出无差异。

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