通过 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 网络进行定制。

更新：
回答 cmets 中的其他问题：

我其实是打算使用自签名证书的，所以我想我只需要提取它并添加到客户端的信任库中？

是的，没错。但是在最初链接的 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()。这会导致 QMgr 请求客户端的证书。
5. 如果使用SSLPEER，请将其设置为所需的值。

此过程会隔离可能出现的问题，以便您随时知道去哪里寻找。如果该过程在步骤 #3 中失败，则说明应用程序的 SSL 配置存在问题，或者无法验证 QMgr 的证书。如果过程在步骤#4 中失败，那么我们知道应用程序的 SSL 配置是正确的，并且它喜欢 QMgr 的证书但 QMgr 不喜欢应用程序证书。如果我们到达第 5 步，那么只需正确获取 SSLPEER 值即可。

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