如何为 Websphere MQ 客户端启用带有客户端证书的 SSL？

Question

我们是更大环境中的一个应用程序和一些数据接口的客户端，使用 Websphere MQ 8.x。我们的应用程序是在 WildFly 9 上运行的 Java EE 应用程序，它使用资源适配器 (wmq.jmsra.rar)，它与 ​​EAR 文件一起部署在同一个 AS 中。我们在两个方向与 MQ 服务器交互。因此，一方面我们有一些 MDB（由于历史起源仍然是没有注释的 EJB 2.x 格式）列出了一些队列，这些 MDB 由 ejb-jar.xml 部署描述符配置，包含激活配置属性 destinationType, channel, queueManager, hostName, username, password .另一方面，我们有一个发送方，它通过 JNDI 查找队列连接工厂和队列并创建连接。

现在我们需要与新建立的 MQ 服务器通过 SSL 和客户端证书进行通信。我们从服务器人员那里为我们的机器获得了这样的证书。所以我的问题是：

• 必须做些什么才能使其与上述设置一起使用？
• 这是否可能纯粹通过配置来实现，从而对应用程序透明，或者让应用程序专门使用 SSL、提供证书或类似的东西？
• 这是否与应用程序其他部分已使用的任何其他密钥库冲突？
• 是否需要一些额外的 IBM MQ 软件才能使其工作？ （我们的客户端只是RAR，没有安装任何软件，我们这边不需要建立MQ服务器。）

---

更新：我开始为 VM 设置全局 JSSE 属性，因为它解决了我的问题。

需要设置以下参数：

-Djavax.net.ssl.trustStore=<location of trustStore>
-Djavax.net.ssl.keyStore=<location of keyStore>
-Djavax.net.ssl.keyStorePassword=<password>

另外，由于我使用的是非IBM VM，因此需要设置以下参数：

-Dcom.ibm.mq.cfg.useIBMCipherMappings=false

然后，需要在standalone-full.xml 中的RAR 配置中设置密码套件属性以及我的WildFly 安装的其他连接参数：

<resource-adapter id="wmq.jms.rar">
...
  <connection-definitions>
    <connection definition ...>
      <config-property name="sslCipherSuite">xxx</config-property>
...
</resource-adapter">

最后，列在队列中的 MDB 也必须配置为使用密码套件，所以在我的情况下，我必须通过为每个 MDB 添加将其添加到 ejb-jar.xml 中：

<activation-config-property>
  <activation-config-property-name>sslCipherSuite</activation-config-property-name>
  <activation-config-property-value>xxx</activation-config-property-value>
<activation-config-property>

Answer 1

OP 在 cmets 中声明他们使用 OpenJDK 8 并使用 IBM MQ v9.0.0.1 资源适配器，以下两个已知问题在该版本中都已修复，但将这些信息放在这里是为了其他人的利益可能尚未发布修复这些问题的版本：

• APAR IV66840：在 8.0.0.2 之前不支持非 IBM JRE 中的 TLS 密码规范。

• APAR IT10837：如果使用非 IBM JRE 查找包含客户端证书的 KeyStore，WildFly 9 可能会遇到另一个问题，此问题已在 8.0.0.5 中修复。

---

资源适配器包含支持 TLS 的 MQ 功能，但使用底层 JSSE 进行实际加密。

基于 RFC 5246，它建议 TLS 客户端只应返回一个合适的证书，该证书基于服务器发送“可接受的证书授权的可分辨名称 [X501] 列表，以 DER 编码格式表示.”，这意味着如果您的 keyStore 中用于不同用途的证书（例如：现有的非 MQ 证书和 MQ 证书）未由同一 CA 链签名，并且您连接到的各种 TLS 服务器不接受来自密钥存储中其他证书的 CA 的证书（例如：现有的非 MQ 证书和 MQ 证书），那么 JSSE 将向每个服务器返回适当的证书。

例如，如果现有的非 MQ 证书由内部 CA 签署，而 MQ 证书由另一家公司的 CA 签署，则 MQ 公司不太可能信任您的内部 CA 证书，相反，您的其他公司不太可能信任您的内部 CA 证书。您连接的非 MQ TLS 服务器会信任其他公司的 CA。由于 JSSE 将仅返回远程服务器信任的证书，因此它们不应相互影响。您只需将 MQ 证书添加到您现有的密钥库中。

来自 RFC 5246 相关部分的引用位于本文底部。

---

@a_cornish_pasty 回答您的问题“Use specific keystore for JMS”也是一种替代方法，因为它允许您指定一个与 Wildfly 其余部分使用的密钥库分开的密钥库，该密钥库可能只有 MQ 证书，所以没有机会导致现有密钥库和证书出现问题。

---

RFC 5246 Section 7.4.4 声明如下：

7.4.4。证书申请

何时发送此消息：

非匿名服务器可以选择从 客户端，如果适用于选定的密码套件。这 消息，如果发送，将立即跟随 ServerKeyExchange 消息（如果已发送；否则，此消息遵循 服务器的证书消息）。

然后它继续状态：

certificate_authorities

可接受的可分辨名称 [X501] 列表 certificate_authorities，以 DER 编码格式表示。 这些 专有名称可以为 根 CA 或从属 CA；因此，此消息可用于 描述已知的根以及所需的授权空间。 如果 certificate_authorities 列表为空，那么客户端可以 发送适当的 ClientCertificateType 的任何证书， 除非有相反的外部安排。

RFC 5246 Section 7.4.6 声明如下：

7.4.6。客户证书

何时发送此消息：

这是客户端在收到一个消息后可以发送的第一条消息 ServerHelloDone 消息。 仅当服务器发送此消息 请求证书。 如果没有合适的证书可用， 客户端必须发送包含 no 的证书消息 证书。 也就是说，certificate_list 结构有一个 长度为零。如果客户端不发送任何证书，则 服务器可以自行决定是否继续握手而不 客户端身份验证，或以致命的握手失败响应 警报。此外，如果证书链的某些方面是 不可接受的（例如，它没有由已知的、受信任的 CA 签名）， 服务器可以自行决定是否继续握手 （考虑到客户端未经身份验证）或发送致命警报。

然后它继续状态：

• 如果证书请求中的 certificate_authorities 列表 消息非空，证书中的证书之一 链应该由列出的 CA 之一发行。