2

我配置WebSphere MQ v6.0.1.1为由 Java 客户端使用JNDI和JMSvia访问SSL。我在不同的机器上尝试了客户端和服务器，在同一台机器上。我在客户端没有遇到同样的异常，但它与连接问题有关。在服务器端，我的日志中没有任何内容。

不同的机器客户端错误：Thread pool thread #0, Exception sending alert: java.net.SocketException: Software caused connection abort: socket write error

*** ServerHelloDone
*** Certificate chain
***
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
Thread pool thread #0, WRITE: TLSv1 Handshake, length = 141
SESSION KEYGEN:
PreMaster Secret:
0000: 03 01 DB 7F 1B 78 46 24   D1 B3 7F 8F E4 2B 2D 35  .....xF$.....+-5
0010: 1B EB FF C9 01 C9 EC 12   07 0F F9 88 A9 12 45 77  ..............Ew
0020: 22 AE 79 17 C2 9D 4C 97   04 3E BA 91 1F 14 68 44  ".y...L..>....hD
CONNECTION KEYGEN:
Client Nonce:
0000: 50 76 7B FB 0D 45 F0 8D   EF 54 E0 AB 2C 3A D4 7D  Pv...E...T..,:..
0010: 24 52 FB FB 4F F4 1D E4   CC 2C 4E BA 8B CA 3E 54  $R..O....,N...>T
Server Nonce:
0000: 00 00 00 00 8F 53 C4 4D   2F 2F 41 AA EB 0A 80 2D  .....S.M//A....-
0010: D0 E4 51 2A CC BC EE 94   92 BD CD E0 9B C9 EB 3D  ..Q*...........=
Master Secret:
0000: 9D 93 ED F3 8A 97 39 7F   71 5F 34 52 30 A6 8E 38  ......9.q_4R0..8
0010: BC 17 59 28 78 63 AA 66   63 D0 EE 1C C6 54 CA D1  ..Y(xc.fc....T..
0020: F2 F0 ED 7E D7 81 33 C6   E3 1B 7C 46 C0 FB C8 5C  ......3....F...\
Client MAC write Secret:
0000: 57 56 3D 05 B1 27 BE 56   A8 FD 07 64 0A 96 62 F2  WV=..'.V...d..b.
0010: AE AF B5 98                                        ....
Server MAC write Secret:
0000: F5 C7 B2 D2 79 11 90 6C   C8 FD 86 8B E5 AE 59 71  ....y..l......Yq
0010: B2 A7 AB D3                                        ....
Client write key:
0000: 54 FD FD 8B C2 B4 8B 3F   38 23 25 5A 8A 41 26 9B  T......?8#%Z.A&.
Server write key:
0000: 6D 9C C0 97 ED 21 3F 0E   0A FB E2 2B EE C0 5F 01  m....!?....+.._.
... no IV used for this cipher
Thread pool thread #0, WRITE: TLSv1 Change Cipher Spec, length = 1
*** Finished
verify_data:  { 182, 85, 56, 238, 250, 233, 155, 119, 224, 254, 23, 196 }
***
Thread pool thread #0, WRITE: TLSv1 Handshake, length = 36
Thread pool thread #0, READ: TLSv1 Change Cipher Spec, length = 1
Thread pool thread #0, READ: TLSv1 Handshake, length = 36
*** Finished
verify_data:  { 215, 140, 30, 150, 82, 161, 85, 160, 127, 189, 226, 74 }
***
%% Cached client session: [Session-1, SSL_RSA_WITH_RC4_128_SHA]
Thread pool thread #0, setSoTimeout(120000) called
Thread pool thread #0, WRITE: TLSv1 Application Data, length = 150
Thread pool thread #0, READ: TLSv1 Application Data, length = 56
Thread pool thread #0, WRITE: TLSv1 Application Data, length = 48
Thread pool thread #0, called close()
Thread pool thread #0, called closeInternal(true)
Thread pool thread #0, SEND TLSv1 ALERT:  warning, description = close_notify
Thread pool thread #0, WRITE: TLSv1 Alert, length = 22
Thread pool thread #0, Exception sending alert: java.net.SocketException: Software caused connection abort: socket write error

同机客户端错误：Thread pool thread #0, Exception sending alert: java.net.SocketException: Broken pipe

似乎客户端在写入，而服务器已经关闭了连接。

编辑：

10/10/12  2:26:23 PM - Process(10995.12) User(mqm) Program(amqrmppa)
AMQ9631: The CipherSpec negotiated during the SSL handshake does not match the
required CipherSpec for channel 'SSL.CHANNEL'.

EXPLANATION:
There is a mismatch between the CipherSpecs on the local and remote ends of
channel 'SSL.CHANNEL'. The channel will not run until this mismatch is
resolved. The CipherSpec required in the local channel definition is
'RC4_SHA_US'. The name of the CipherSpec negotiated during the SSL handshake is
'RC4_SHA_US'. A code is displayed if the name of the negotiated CipherSpec
cannot be determined.
ACTION:
Change the channel definitions for 'SSL.CHANNEL' so the two ends have matching
CipherSpecs and restart the channel. If the certificate in use by one end of
the channel is a Global Server Certificate, then the negotiated CipherSpec may
not match that specified on either end of the channel. This is because the SSL
protocol allows a Global Server Certificate to automatically negotiate a higher
level of encryption. In these cases specify a CipherSpec which meets the
requirements of the Global Server Certificate.
----- amqccisa.c : 851 --------------------------------------------------------
10/10/12  2:26:23 PM - Process(10995.12) User(mqm) Program(amqrmppa)
AMQ9999: Channel program ended abnormally.

EXPLANATION:
Channel program 'SSL.CHANNEL' ended abnormally.
ACTION:
Look at previous error messages for channel program 'SSL.CHANNEL' in the error
files to determine the cause of the failure.
----- amqrmrsa.c : 468 --------------------------------------------------------

编辑2：

     1 : DIS CHANNEL(SSL.CHANNEL) SSLCIPH
AMQ8414: Display Channel details.
   CHANNEL(SSL.CHANNEL)                    CHLTYPE(SVRCONN)
   SSLCIPH(RC4_SHA_US)

密码使用客户端使用JMSAdmin：

DEFINE QCF(QCF_NAME) SYNCPOINTALLGETS(YES) HOSTNAME(HOST) PORT(1414) TRANSPORT(client) QMANAGER(MYQMGR) CHANNEL(SSL.CHANNEL) SSLCIPHERSUITE(SSL_RSA_WITH_RC4_128_SHA)

基于SSL CipherSpecs 和 CipherSuites RC4_SHA_US似乎匹配SSL_RSA_WITH_RC4_128_SHA。

4

1 回答 1

0

在与 QMgr 相同的主机上运行客户端时，有可能使用绑定模式（共享内存）而不是通过网络堆栈进行连接。由于绑定模式连接不使用网络堆栈，因此 SSL 没有任何区别。

假设客户端在这两种情况下都通过网络进行连接，那么客户端在一台或另一台服务器上的位置不会影响 SSL 连接，只是客户端配置在一个实例与另一个实例之间存在差异。客户端仍在通过网络堆栈并向 QMgr 的侦听器提交连接请求。客户端以相同的方式找到它的密钥库，并且 QMgr 看到的只是呈现给侦听器的连接请求。因此，如果您在两个客户端实例之间得到不同的结果，请查找配置差异。

我在 WMQ 上调试 SSL 连接的方法是按照以下顺序进行，确保每个步骤在进行下一步之前都有效：

  1. 让通道在没有 SSL 的情况下运行。这将验证通道名称是否拼写正确、端点之间存在网络路由、QMgr 的侦听器正在运行以及客户端是否指向正确的端口。
  2. 让通道在 SVRCONN 定义设置为 的情况下运行SSLCAUTH(OPTIONAL)。这将执行与您的浏览器类似的匿名 SSL 连接。QMgr 向客户端提供证书，但不要求返回。这验证了 QMgr 可以找到它的证书，并且客户端可以找到它的信任存储并正确验证 QMgr 的证书。
  3. 将 SVRCONN 通道设置为SSLCAUTH(REQUIRED)。这现在需要客户端找到它的密钥库（在最后一步中它只需要它的信任库）并能够找到它的证书。它还要求 QMgr 能够验证客户端的证书。

最后两个步骤之间的差异有助于通过一次仅在一个方向上测试 SSL 凭证交换来隔离问题。

您提到发生这种情况时“日志中没有任何内容”。哪个日志？有两组错误日志。一个是服务器全局日志，{WMQ home}/errors另一个是 QMgr 错误日志{WMQ home}/QMgrs/{QMgr name}/errors。当 MQ 可以识别与错误关联的 QMgr 时，会将错误日志条目写入 QMgr 的错误日志。但是，当请求 SSL 连接时，MQ 直到SSL 连接完成后才知道该连接请求了哪个 QMgr。因此，在全局错误日志中报告了服务器端的许多 SSL 协商错误。

我建议执行上述步骤以确定哪个 SSL 凭证交换失败，然后在 QMgr 和全局错误日志文件中查找错误日志条目。如果这不能解决问题，请更新您的问题，注意过程中失败的步骤以及在哪个日志中标识的任何错误日志条目。

此外，MQ 的 V6 已于上个月停止服务。迁移到受支持的 WMQ 客户端和服务器版本将允许您打开 PMR，将提供更好的 Java/JMS 性能，并允许您使用更安全的密码，例如 SHA-2 哈希和由支持的新椭圆曲线加密GSKit 8. 由于 WMQ V6 不支持，最多只会发布一个额外的 Fix Pack，之后该版本中的安全漏洞将不会得到解决。如果您使用 SSL，我认为安全性有些重要，并且您会希望使用在发现新漏洞时会收到修复的版本。

更新
响应关于全局服务器证书的问题更新，有必要了解 WMQ 如何实现 SSL/TLS。建立连接后，TLS 协商（如果您指定 SSL，WMQ 使用 SSL 密码执行 TLS 会话）遵循规范，并且规范允许对密码套件进行协商。当使用全局服务器证书时，证书可以指定可接受的最小密码强度，这会影响协商。

当 TLS 会话成功完成时，连接将被传递给 WebSphere MQ。只有这样 QMgr 才会检查通道参数，例如“请求的连接是什么 QMgr？” 或者，更重要的是，“连接的协商密码规范是否与通道定义匹配？” 通常，它会因客户端和服务器之间的不匹配而失败。使用全局服务器证书，它可能会因为协商的密码规范与证书指定的可接受的最小值不匹配而失败。

错误消息的意思是，客户端指定的密码套件可能与通道中指定的密码规范完全匹配，但仍然无法连接，因为全局服务器证书指定的最小密码强度大于所使用的密码强度客户和 QMgr。在信息中心的Cipherspec mismatches中有更多关于此的信息，但在这种情况下，错误消息几乎与信息中心一样提供信息。

于 2012-10-10T10:53:32.207 回答