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

Question

我正在准备一个通过SSL连接到Websphere MQ 7.0的测试环境，所以在开始从JMS端配置SSL连接之前，我必须自己在Websphere MQ上配置SSL 。

因此，我正在尝试按照这些步骤为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'日志（使用选项-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为例介绍了这个过程，以及导入root和中间签名者证书的屏幕截图。 本文是关于续订WebSphere MQ证书的，但本文的第一部分创建了一个kdb文件和一个签名请求，然后导入了CA证书和签名的证书。

让我们也到达正确的信息中心。 请查看WMQ v7.0信息中心有关使用CA签名证书的部分。 您正在查看的是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通道时，我总是使用以下过程：

1. 在没有SSL的情况下运行通道。 这证明基本通信路径正在工作（侦听器运行，端口匹配，通道对象定义匹配等）。
2. 如果这是QMgr第一次使用SSL，或者kdb已更改，请务必发出REFRESH SECURITY TYPE(SSL)命令。
3. 通过在QMgr和客户端指定相同的密码套件来启用SSL，但要确保QMgr的SVRCONN通道设置为SSLCAUTH(OPTINAL) SSLPEER() 。 这将验证客户端是否接受QMgr的证书。 只有在此工作时，请转到下一步。
4. 现在将QMgr的SVRCONN SSLCAUTH(REQUIRED) SSLPEER()为SSLCAUTH(REQUIRED) SSLPEER() 。 这会导致QMgr请求客户端的证书。
5. 如果使用SSLPEER将其设置为所需的值。

此过程隔离了可能出现的问题，以便您随时知道要查找的位置。 如果该过程在步骤＃3中失败，则存在应用程序的SSL配置问题，或者它无法验证QMgr的证书。 如果该过程在步骤＃4中失败，那么我们知道应用程序的SSL配置是合理的，并且它喜欢QMgr的证书，即QMgr不喜欢应用程序证书。 如果我们进入第5步，那么只需要获得SSLPEER值就可以了。

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