如何为Websphere MQ客户端启用带有客户端证书的SSL？ [英] How to enable SSL with client certificate for Websphere MQ client?

问题描述

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

We are one application in a larger environment and a client for some data interface, using Websphere MQ 8.x. Our application is a Java EE application running on a WildFly 9 which uses a resource adaptor (wmq.jmsra.rar) which is deployed together with the EAR file in the same AS. We interact with the MQ Server in both directions. So we have on the one hand some MDBs (which are due to historical origins still in EJB 2.x format without annotations) listining to some queues and which are configured by the ejb-jar.xml deployment descriptor, containing the activation config properties destinationType, channel, queueManager, hostName, username, password. On the other hand we have a sender which lookups a queue connection factory and a queue via JNDI and creates a connection.

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

Now we have the requirement with a newly established MQ server to communicate via SSL and a client certificate. We got such a certificate from the server people for our machine. So my questions are:

• 要使其与上述设置一起使用需要做些什么？


• 这纯粹是通过配置实现的，因此应用程序是透明的，还是应用程序专门使用SSL，提供证书或类似的东西？


• 这是否与应用程序的其他部分已经使用的任何其他密钥库冲突？


• 是否需要一些额外的IBM MQ软件才能使其正常工作？ （我们的客户只是RAR，没有安装任何软件，我们这边也没有建立MQ服务器。）

• What has to be done to make it work with the setup described above?
• Is this possible purely by configuration and thus transparent for the application or has the application to specifically use SSL, present the certificate or something similar?
• Does this conflict with any other keystore already used by some other part of the application?
• Is some additional IBM MQ software needed to make it work? (Our client is just the RAR, no software is installed and no MQ server on our side should be established.)

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

Update: I went for setting the global JSSE properties for the VM as it solved my problem as a start.

必须设置以下参数：

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

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

Additionally, since I am using non-IBM VM, there was the following paramter to set:

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

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

Then, it was necessary to set the cipher suite property on the RAR configuration in standalone-full.xml together with the other connection parameters of my WildFly installation:

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

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

And finally, the MDBs listining on the queues also had to be configured to use the cipher suite, so in my case I had to add that in the ejb-jar.xml by adding for each MDB:

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

推荐答案

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

OP stated in the comments that they use OpenJDK 8 and are using the IBM MQ v9.0.0.1 resource adapter, both of the following known problems are fixed in that release, but putting this information here for the benefit of others who may not yet be at a release where these are fixed:

• APAR IV66840 ：直到8.0.0.2才支持非IBM JRE中的TLS密码规范。

• APAR IV66840: TLS cipherspecs in non-IBM JREs were not supported until 8.0.0.2.

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

APAR IT10837: WildFly 9 may hit another issue if using a non-IBM JRE in finding the KeyStore that contains the client cert, this is fixed in 8.0.0.5.

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

The resource adapter includes the MQ functionality to support TLS but uses the underlying JSSE for the actual encryption.

基于RFC 5246，它建议TLS客户端只应根据发送可接受的certificate_authorities的可分辨名称[X501]列表，以DER编码格式表示。，这意味着如果您的keyStore中的证书用于不同的用途（例如：现有的非MQ证书和MQ证书）不由同一CA链签名，并且您连接的各种TLS服务器不接受来自密钥库中其他证书的CA的证书（例如：现有的非MQ证书和MQ证书）然后JSSE将向每个证书返回相应的证书。

Based on RFC 5246 it suggests that the TLS Client should only return a cert that is suitable based on the the server sending "A list of the distinguished names [X501] of acceptable certificate_authorities, represented in DER-encoded format.", this would mean that if the certs in your keyStore for the different uses (ex: existing non-MQ certs and MQ certs) are not signed by the same CA chain, and the various TLS servers you connect to do not accept certs from the CA of other certs in your key store (ex: existing non-MQ certs and MQ certs) then JSSE will return the appropriate cert to each.

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

For example if existing non-MQ certs are signed by a Internal CA and the MQ cert is signed by another company's CA, it is highly unlikely that the MQ company would trust your internal CA certs, conversely it is unlikely that your other non-MQ TLS servers you connect to would trust the other company's CA. Since JSSE would return only a cert that was trusted by the remote server they should not impact each other. You would just need to add the MQ cert to your existing key store.

RFC 5246相关章节的引言位于本文的底部。

Quotes from the relevant sections of RFC 5246 are at the bottom of this post.

@a_cornish_pasty回答你的问题使用特定的密钥库进行JMS 也是一种替代方法，因为它允许您指定一个单独的密钥库来保存Wildfly的其余部分，这个密钥库只能拥有MQ证书，因此不存在导致现有密钥库和证书出现问题的可能性。

@a_cornish_pasty answer to your question "Use specific keystore for JMS" is also an alternative as it would allow you to specify a separate key store from what the rest of Wildfly uses, this key store could have ONLY the MQ cert, so no chance of causing an issue with the existing key store and certs.

RFC 5246第7.4.4节规定如下：

7.4.4。证书申请

7.4.4. Certificate Request

此邮件将被发送：

非匿名服务器可以选择请求来自
客户端的证书，如果适用于所选的密码套件。此
消息（如果已发送）将紧跟在ServerKeyExchange
消息之后（如果已发送;否则，此消息将在
服务器的证书消息之后）。

A non-anonymous server can optionally request a certificate from the client, if appropriate for the selected cipher suite. This message, if sent, will immediately follow the ServerKeyExchange message (if it is sent; otherwise, this message follows the server's Certificate message).

然后进入状态：

certificate_authorities

certificate_authorities

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

A list of the distinguished names [X501] of acceptable certificate_authorities, represented in DER-encoded format. These distinguished names may specify a desired distinguished name for a root CA or for a subordinate CA; thus, this message can be used to describe known roots as well as a desired authorization space. If the certificate_authorities list is empty, then the client MAY send any certificate of the appropriate ClientCertificateType, unless there is some external arrangement to the contrary.

RFC 5246第7.4.6节陈述如下：

7.4.6。客户证书

7.4.6. Client Certificate

此消息将被发送：

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

This is the first message the client can send after receiving a ServerHelloDone message. This message is only sent if the server requests a certificate. If no suitable certificate is available, the client MUST send a certificate message containing no certificates. That is, the certificate_list structure has a length of zero. If the client does not send any certificates, the server MAY at its discretion either continue the handshake without client authentication, or respond with a fatal handshake_failure alert. Also, if some aspect of the certificate chain was unacceptable (e.g., it was not signed by a known, trusted CA), the server MAY at its discretion either continue the handshake (considering the client unauthenticated) or send a fatal alert.

然后进入状态：

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

• If the certificate_authorities list in the certificate request message was non-empty, one of the certificates in the certificate chain SHOULD be issued by one of the listed CAs.

这篇关于如何为Websphere MQ客户端启用带有客户端证书的SSL？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！