MSSQL JDBC SSL加密连接异常排查：生产环境偶发问题求助

一、为何仅生产环境出现该问题？ #

• 生产环境MSSQL的SSL策略更严格：多数生产环境会强制要求SSL加密连接，且对证书验证规则更严谨（比如不允许未配置信任的自签名证书）；而开发环境可能默认关闭SSL强制验证，或提前导入了测试证书，因此问题不会暴露。
• 网络与连接池复用差异：生产环境连接池规模更大、连接闲置时间更长，当SSL会话过期后重新握手时，网络层面的防火墙/负载均衡规则（比如限制SSL握手超时）或证书信任问题会触发失败；开发环境连接使用频率高，会话不会长时间闲置，或连接池小，问题难以复现。
• JVM安全配置差异：生产环境JVM通常使用默认信任库（未导入MSSQL的SSL证书），而开发环境可能手动添加了证书，或通过JVM参数禁用了SSL证书验证，避开了握手失败问题。

二、为何并非初始就报错？ #

• 连接池初始化时SSL握手正常：应用启动时，Hikari会创建初始连接，此时SSL会话处于有效期内，证书验证通过（服务器证书未过期、会话缓存有效），因此初期无报错。
• 连接复用触发SSL会话重连：当连接闲置超过idleTimeout，MSSQL服务器的SSL会话会超时失效，Hikari复用该连接时需要重新进行SSL握手；此时若存在证书信任问题（比如生产环境证书更新后JVM未同步），就会握手失败，抛出连接超时异常。
• 连接池检测机制延迟暴露问题：Hikari的连接健康检测并非每次复用都触发，仅当连接闲置时间过长或被标记为无效时才会执行检测，此时SSL握手失败才会被捕获并上报。

三、是否与未指定JDBC版本有关？ #

• 是，这是核心诱因之一：
  • SpringBoot父POM会默认管理mssql-jdbc版本，但不同SpringBoot版本对应的JDBC版本可能存在Java15兼容性缺陷。部分旧版本的mssql-jdbc在Java15下处理SSL会话复用存在bug，初期连接可正常建立，但会话过期后重新握手会抛出Unexpected rethrowing异常。
  • 未指定版本时，若SpringBoot引入的默认JDBC版本对Java15的TLS协议支持不完善，生产环境严格的SSL配置会触发该bug，而开发环境宽松的配置（比如允许非SSL连接）掩盖了问题。

解决建议 #

• 显式指定兼容Java15的mssql-jdbc版本：选择官方明确支持Java15的稳定版本（如12.x系列），在POM中添加：

<dependency>
    <groupId>com.microsoft.sqlserver</groupId>
    <artifactId>mssql-jdbc</artifactId>
    <version>12.6.0.jre15</version>
</dependency>

• 修正JDBC URL的SSL参数：若使用自签名证书，添加encrypt=true;trustServerCertificate=true；若使用正式CA证书，确保JVM信任库包含该证书，或在URL中指定trustStore=/path/to/truststore;trustStorePassword=yourpassword。
• 优化Hikari连接池配置：缩短idleTimeout减少连接闲置时间，配置connectionTestQuery=SELECT 1确保复用前验证连接有效性，适当增大connectionTimeout给SSL握手预留足够时间。
• 同步生产环境JVM信任库：将MSSQL的SSL证书导入到生产JVM的默认信任库（$JAVA_HOME/jre/lib/security/cacerts），或使用自定义信任库。

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