java - 通过SSL使用JMS连接到WebSphere MQ 7.0

Question

我正在准备通过SSL连接到Websphere MQ 7.0的测试环境，因此在启动configuring the SSL connection from JMS side之前，我必须在Websphere MQ上配置SSL。

因此，我尝试按照these步骤为Websphere MQ创建SSL证书。但是，当我尝试使用gsk7cmd.exe -cert -receive -db key.kdb -pw pass -file QMANAGER_signed.arm命令将签名证书添加到存储库时，出现错误:

An attempt to receive the certificate has failed.
All the signer certificates must exist in the key database.

我什至尝试了C命令 gsk7capicmd，但它也失败了，并显示以下错误:

Error: 146

Error id: GSKKM_ERR_INVALID_CERT_CHAIN
Details: QMANAGER_signed.arm

更新1:

我使用WMQ SSL向导来创建正确的配置。配置进行得很顺利，但是当我运行SSL向导随附的JMS示例时，出现错误: MQJE001: Completion Code '2', Reason '2397'SSL日志(使用 -Djavax.net.debug=all选项)显示以下错误:

Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2397;AMQ9771: SSL handshake failed. [1=javax.net.ssl.SSLHandshakeExcep
tion[Remote host closed connection during handshake],3=localhost/127.0.0.1:1414 (localhost),4=SSLSocket.startHandshake,5
=default]
        at com.ibm.mq.jmqi.remote.internal.RemoteTCPConnection.protocolConnect(RemoteTCPConnection.java:995)
        at com.ibm.mq.jmqi.remote.internal.system.RemoteConnection.connect(RemoteConnection.java:989)
        at com.ibm.mq.jmqi.remote.internal.system.RemoteConnectionPool.getConnection(RemoteConnectionPool.java:293)
        at com.ibm.mq.jmqi.remote.internal.RemoteFAP.jmqiConnect(RemoteFAP.java:1371)
        at com.ibm.msg.client.wmq.internal.WMQConnection.<init>(WMQConnection.java:331)
        ... 7 more
Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
        at com.ibm.jsse2.jc.a(jc.java:380)
        at com.ibm.jsse2.jc.g(jc.java:115)
        at com.ibm.jsse2.jc.a(jc.java:240)
        at com.ibm.jsse2.jc.startHandshake(jc.java:54)
        at com.ibm.mq.jmqi.remote.internal.RemoteTCPConnection.protocolConnect(RemoteTCPConnection.java:989)
        ... 11 more
Caused by: java.io.EOFException: SSL peer shut down incorrectly
        at com.ibm.jsse2.a.a(a.java:7)
        at com.ibm.jsse2.jc.a(jc.java:493)
        ... 15 more

更新2:

使用他的答案中提到的T.Rob的诊断技术，我仍然停留在第3点，并具有与以前相同的错误。

Answer 1

您看到的错误是因为您的密钥库没有签名CA的根和/或中间签名者证书。当您从证书颁发机构处获得签名证书时，必须先对其进行验证，然后再将其添加到密钥库中。几乎任何人都可以拦截您的签名请求并签署证书。收到时对其进行验证的步骤可确保它是由您真正信任的CA签名的，而不是由某些匿名中间人签名的。

验证证书的方法是通过对照KDB中CA的公钥检查CA签名。为此，当您尝试接收已签名的证书时，CA的证书必须已经在KDB中。如果CA使用中间签名者证书(并且由于各种原因，任何商业CA将使用中间证书)，那么您还必须已经导入了中间证书和根证书。这形成了从CA的根证书到任何中间证书到您的签名证书的证书链或证书路径。链中的所有事物都将由其上方的事物进行身份验证，直到到达根为止。您的KDB必须具有整个链，并且由于每个证书均已通过其上一个证书验证，因此您必须从根开始导入所有证书，然后逐步向下进行。

通常，您的CA会在其网站上发布其签名者证书，您可以在其中使用SSL检索它们。提取并导入它们，您将能够收到签名的证书。

碰巧的是，《 The Sphere Online Journal》刚刚发表了一篇文章，以Verisign为例，引导您完成此过程，并提供了导入根和中间签署者证书的屏幕截图。本文是关于Renewing WebSphere MQ Certificates的，但本文的第一部分创建了一个kdb文件和一个签名请求，然后导入了CA证书和已签名的证书。

让我们也带您到正确的信息中心。请查看Using CA Signed Certificates的WMQ v7.0信息中心部分。您正在看的是Message Broker，坦率地说，您链接到的文章有些混乱。我将解决此问题。对于初学者来说，在一个kdb中创建证书，对其进行签名，然后将其导出，删除，然后将其导入到QMgr的KDB中的想法纯属垃圾。只需在QMgr自己的KDB文件中生成CSR，然后直接将签名的证书接收到该文件即可。这要容易得多，这就是上述文章中说明的过程。

最后，如果您转到t-rob.net并从IMPACT 2011下载WMQ安全实验室，则将找到一个实验室指南和一些脚本。这些使用自签名证书，但是脚本可以轻松转换为使用CA签名证书，然后针对WMQ网络进行定制。

更新:
在评论中回应他的其他问题:

我实际上计划使用自签名证书，所以我想我只需要提取它并将其添加到客户的信任库中？

对，那是正确的。但是这是WMB信息中心页面中的一个问题，该问题最初被链接为，它要求您创建标签为qmgrname而不是ibmwebspheremqqmgrname的证书。 QMgr根据标签找到其证书，因此它必须与指定的格式匹配。因此，当您创建自签名证书时，请确保标签为文字ibmwebspheremq，QMgr名称折叠为小写字母。如果您使用错误的标签制作了证书，则始终可以将其导出到P12文件，然后再使用正确的标签将其导入到新的KDB中。

我使用WMQ安全实验室中提到的WMQ SSL向导来创建正确的配置。配置进行得很顺利，但是当我运行SSL向导随附的JMS示例时，出现错误MQJE001: Completion Code '2', Reason '2397'，SSL日志显示以下错误main, received EOFException: error main, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake main, SEND TLSv1 ALERT: fatal, description = handshake_failure
有几种原因可能导致这种情况发生。我将建议一些诊断技术，而不是全部介绍它们。设置SSL通道时，我始终使用以下过程:

使通道在没有SSL的情况下运行。这证明基本通信路径正在工作(侦听器正在运行，端口匹配，通道对象定义匹配等)。

如果这是QMgr首次使用SSL，或者kdb已更改，请确保发出REFRESH SECURITY TYPE(SSL)命令。

通过在QMgr和客户端指定相同的密码套件来启用SSL，但请确保QMgr的SVRCONN通道设置为SSLCAUTH(OPTINAL) SSLPEER()。这验证客户端接受QMgr的证书。仅当此方法有效时，请转到下一步。

现在将QMgr的SVRCONN更改为SSLCAUTH(REQUIRED) SSLPEER()。这将导致QMgr请求客户端的证书。

如果使用SSLPEER，请将其设置为所需的值。

此过程将可能的问题隔离开来，以便您随时随地都可以看到。如果该过程在步骤＃3中失败，则说明该应用程序的SSL配置存在问题，或者它无法验证QMgr的证书。如果该过程在步骤＃4中失败，则我们知道该应用程序的SSL配置是正确的，并且它喜欢QMgr的证书，而QMgr不喜欢该应用程序证书。如果转到步骤5，则只需要正确设置 SSLPEER值即可。

因为您的握手失败似乎是由于QMgr关闭了TCP连接，所以我假设您有 SSLCAUTH(REQUIRED)(顺便说一下，这是默认值)，并且QMgr没有该应用程序的证书或您正在尝试使用匿名连接，而客户端不需要个人证书。在这种情况下，设置 SSLCAUTH(OPTIONAL)将使您超越故障点-尽管可能会到达一个全新的故障点。