我来帮你拆解这个WebSphere下的connection reset问题——毕竟相同代码在独立Java里能跑，说明问题肯定出在WebSphere的环境配置上，和你怀疑的密码套件（应该是笔误的SHA384而非SHA386）不兼容方向完全对路。结合WebSphere v8.5.5.11的特性，给你梳理排查和解决思路：

你的代码本身没问题，矛盾点在于：独立Java环境直接使用JVM默认SSL配置，而WebSphere有自己的安全管控体系，会覆盖JVM层面的SSL设置——哪怕你代码里指定了密码套件，也可能被WebSphere的全局配置给“架空”了，最终导致握手失败触发connection reset。

1. 检查WebSphere全局SSL密码套件配置 #

WebSphere不会直接沿用JVM的密码套件列表，必须在控制台手动配置：

• 登录WebSphere控制台，依次进入：安全 > SSL证书和密钥管理 > SSL配置 > 你的SSL配置（比如DefaultSSLSettings） > 质量保护（QoP）设置
• 查看当前“密码套件组”，确认是否包含你代码中指定的TLS_xxx_SHA384类套件。如果没有：
  • 点击“密码套件组”旁的「管理套件」，找到对应SHA384的套件（比如TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384），添加到当前组
  • 额外确认：安全 > 全局安全 > SSL和证书管理 > 配置SSL环境 > 协议是否设置为TLSv1.2（如果目标主机要求的话），WebSphere 8.5.5.11默认可能未完全启用TLS1.2

2. 验证WebSphere捆绑JDK的密码套件支持 #

你用的捆绑JDK 1.8.64版本偏老，部分高强度密码套件可能默认被禁用：

• 找到WebSphere安装目录下的jre/lib/security/java.security文件，检查jdk.tls.disabledAlgorithms参数，若包含SHA384相关套件，直接移除
• 可以在独立Java项目中运行这段代码，获取支持的密码套件列表，再和WebSphere环境下的输出对比，看是否缺失目标套件：

import javax.net.ssl.SSLContext;
import java.util.Arrays;

public class CipherSuiteCheck {
    public static void main(String[] args) throws Exception {
        System.out.println(Arrays.asList(SSLContext.getDefault().getSupportedSSLParameters().getCipherSuites()));
    }
}

3. 强制代码使用自定义SSLContext（绕过WebSphere全局配置） #

如果不想修改WebSphere全局配置，可以在代码里完全独立初始化SSL上下文，避免被WebSphere的安全组件干扰：

@Singleton 
@Startup 
public class ClientStart { 
    @PostConstruct 
    public void init() {
        try {
            // 初始化TLS1.2上下文
            SSLContext sslContext = SSLContext.getInstance("TLSv1.2");
            sslContext.init(null, null, new SecureRandom());
            
            // 指定需要的SHA384密码套件
            SSLParameters sslParams = sslContext.getDefaultSSLParameters();
            sslParams.setCipherSuites(new String[]{"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"}); // 替换为你需要的套件
            
            // 创建Socket并应用参数
            SSLSocketFactory factory = sslContext.getSocketFactory();
            SSLSocket socket = (SSLSocket) factory.createSocket("目标主机IP", 端口号);
            socket.setSSLParameters(sslParams);
            
            // 后续连接逻辑...
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

注意：这种方式要避免使用WebSphere提供的连接池或HTTP客户端，改用原生Socket或标准Java HttpClient，防止被WebSphere接管配置。

4. 开启SSL调试日志定位细节 #

如果以上步骤还没解决，开启WebSphere的SSL日志能帮你看到握手失败的具体原因：

• 控制台进入：服务器 > WebSphere应用服务器 > 你的服务器 > 调试服务
• 添加调试参数：-Djavax.net.debug=ssl,handshake
• 重启服务器后重现错误，查看profiles/你的Profile/logs/你的Server/SystemOut.log，日志里会详细输出SSL握手时的套件协商过程，能直接看到是否是套件不匹配导致的失败。

90%的概率是WebSphere全局SSL配置没启用你需要的SHA384密码套件——毕竟独立Java环境不受WebSphere安全管控，能直接用JVM默认支持的套件。先从控制台配置入手排查，再结合日志验证，应该能快速解决问题。

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