Question

我将WebSphere MQ v6.0.1.1配置为由Java客户端使用JNDI和JMS通过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)

Cipher使用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 and CipherSuites RC4_SHA_US似乎与SSL_RSA_WITH_RC4_128_SHA匹配。

Answer 1

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

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

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

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

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

你提到日志中没有任何内容＆＃34;当这个情况发生时。哪个日志？有两组错误日志。一个是{WMQ home}/errors的服务器全局日志，另一个是{WMQ home}/QMgrs/{QMgr name}/errors的QMgr错误日志。当MQ可以识别与错误相关联的QMgr时，将对QMgr的错误日志进行错误日志条目。但是，当请求SSL连接时，MQ在 SSL连接完成之后之前，不知道连接请求了哪个QMgr。因此，在全局错误日志中报告了服务器端的许多SSL协商错误。

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

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

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

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

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

java.net.SocketException：使用JMS / JNDI和MQ系列断开管道

1 个答案: