Nginx+IBM Security Verify Access连接partner.redhat.com报错求助

核心背景 #

环境：Nginx反向代理 → ISVA（WebSEAL）Docker容器 → 后端partner.redhat.com（自动重定向到connect.redhat.com）
症状：

• /partner连接点访问报错“其他提供商的服务器未响应”
• WebSEAL日志抛出DPWIV1228W错误，具体为GSK_ERROR_SOCKET_CLOSED（SSL握手阶段socket被关闭）
• 其他连接点（如www.redhat.com）正常工作
• 已导入partner.redhat.com和connect.redhat.com证书到pdsrv数据库，IBM工单答复非WebSEAL问题
• Nginx access.log有访问记录，error.log无报错

排查步骤 #

1. 验证ISVA容器的网络连通性与SSL握手能力

• 进入ISVA Docker容器，执行以下命令测试与目标的TCP连接及SSL握手：

  # 测试TCP连通性
  telnet partner.redhat.com 443
  # 测试SSL握手
  openssl s_client -connect partner.redhat.com:443
  # 同时测试重定向后的目标
  openssl s_client -connect connect.redhat.com:443
  

• 检查Docker容器的网络模式，确认容器能正常访问公网，无防火墙/安全组限制容器出口的443端口。

2. 检查WebSEAL连接点的重定向处理配置

• partner.redhat.com会返回3xx重定向到connect.redhat.com，需确认WebSEAL连接点是否开启了跟随服务器重定向：
  • 若用命令行创建连接点，需添加-f参数；
  • 若用ISVA管理界面，在连接点配置中找到“跟随重定向”选项并启用。
• 部分场景下，目标服务器可能在SSL握手阶段提前关闭连接（而非完成HTTP请求后返回重定向），需通过抓包确认具体阶段。

3. 匹配WebSEAL与目标服务器的SSL/TLS兼容性

• GSK_ERROR_SOCKET_CLOSED通常与SSL握手协商失败有关，需对比目标服务器支持的TLS版本和加密套件：

  # 扫描目标服务器的SSL配置
  nmap --script ssl-enum-ciphers -p 443 partner.redhat.com
  

• 检查WebSEAL的SSL配置（配置文件中[ssl]章节）：
  • 确认tls_v12、tls_v13等版本开关是否开启，与目标服务器支持的版本匹配；
  • 确认加密套件列表包含目标服务器支持的套件，避免因套件不匹配导致握手失败；
  • 确保WebSEAL使用的GSKit版本支持目标服务器的SSL特性（如TLS 1.3）。

4. 验证证书导入的完整性与有效性

• 确认导入的是完整证书链（服务器证书+中间CA证书+根CA证书），而非仅服务器证书；
• 在ISVA管理界面的“SSL证书管理”中，检查信任存储里是否包含partner.redhat.com和connect.redhat.com的根/中间CA，且状态为“信任”；
• 证书导入后需重启WebSEAL服务，确保配置生效。

5. 抓包分析SSL握手细节

• 在ISVA容器中执行抓包命令，记录与目标服务器的SSL交互过程：

  tcpdump host partner.redhat.com and port 443 -w ssl_handshake.pcap
  

• 用Wireshark打开抓包文件，重点查看：
  • Client Hello发送后，目标服务器是否返回响应；
  • 是否出现SSL Alert包（如Handshake Failure）；
  • 确认是目标服务器主动关闭连接，还是网络层面的中断。

6. 检查Nginx代理的请求传递

• 虽然其他连接点正常，但可补充Nginx的代理头配置，确保WebSEAL能正确识别前端请求：

  location / {
      # 已有的配置...
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_set_header X-Forwarded-Host $host;
  }
  

• 确认Nginx与ISVA之间的SSL连接正常，可通过openssl s_client -connect a.a.a.a:443测试（a.a.a.a为ISVA容器的IP）。

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