升级RHEL 8后curl与Java调用外部API均出现SSL握手失败问题

数据老陈

2026-10-2

排查思路

优先验证系统加密策略适配性
RHEL 8默认启用全局加密策略（crypto-policies），默认规则禁用了TLS 1.0、TLS 1.1以及多款弱加密套件，若目标API仅支持旧版本TLS协议或弱加密套件，会直接导致握手中断。
执行update-crypto-policies --show查看当前策略，默认值为DEFAULT，可临时切换为兼容旧协议的LEGACY策略验证：
update-crypto-policies --set LEGACY
执行后重新运行curl命令测试，若恢复正常即可确认根因是加密策略限制，后续可自定义加密策略仅放开目标服务需要的协议/套件，无需长期使用LEGACY策略降低系统整体安全性。
验证Zscaler代理SSL拦截兼容性
日志显示你使用了Zscaler代理，该类企业代理默认会做SSL中间人拦截，将目标服务证书替换为代理自签发证书。需确认你curl参数中--cacert指定的xxx.pem文件是否已导入Zscaler的根证书，也可临时添加-k参数跳过证书校验测试连通性，若添加-k后请求正常，补充导入代理根证书到证书文件即可。
手动指定TLS版本测试
分别指定不同TLS版本发起请求，确认目标服务支持的协议范围：
指定TLS 1.2测试：curl --tlsv1.2 --tls-max 1.2 [原有其他参数]
指定TLS 1.1测试：curl --tlsv1.1 --tls-max 1.1 [原有其他参数]
根据返回结果判断是否为TLS版本不匹配问题。
Java侧配置排查
RHEL 8自带的OpenJDK会继承系统全局加密策略，也可单独检查JDK配置文件jre/lib/security/java.security中的jdk.tls.disabledAlgorithms项，确认是否禁用了目标服务需要的加密算法或协议，可临时注释对应限制项测试。
抓包确认握手失败节点
用tcpdump抓取客户端到代理443端口的流量，查看TLS握手阶段客户端Hello携带的协议版本、加密套件列表，确认是否是服务端/代理直接返回RST包中断连接，定位协商失败的具体原因。
代理权限二次验证
虽然日志显示CONNECT请求已返回200，但可二次确认当前机器是否在Zscaler代理的TLS访问白名单中，是否有针对新系统的访问限制规则。