如何使用 Websphere MQ 客户端的客户端证书启用 SSL？
How to enable SSL with client certificate for Websphere MQ client?
我们是更大环境中的一个应用程序和一些数据接口的客户端，使用 Websphere MQ 8.x。我们的应用程序是 WildFly 9 上的 Java EE 应用程序 运行，它使用与 EAR 文件一起部署在同一 AS 中的资源适配器 (wmq.jmsra.rar)。我们在两个方向上都与 MQ 服务器交互。所以我们一方面有一些 MDB（由于历史起源仍然是 EJB 2.x 格式，没有注释）列出一些队列，它们由 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>
OP 在评论中指出他们使用 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 客户端仅 return 一个适合的证书，该证书基于服务器发送“可接受的可分辨名称列表 [X501] certificate_authorities，以 DER 编码格式表示。"，这意味着如果您的 keyStore 中用于不同用途的证书（例如：现有的非 MQ 证书和 MQ 证书）是 not 由同一个 CA 链签名，并且您连接到的各种 TLS 服务器不接受来自密钥库中其他证书的 CA 的证书（例如：现有的非 MQ 证书和 MQ 证书）然后JSSE 将为每个 return 适当的证书。
例如，如果现有的非 MQ 证书由内部 CA 签署，而 MQ 证书由另一家公司的 CA 签署，则 MQ 公司极不可能信任您的内部 CA 证书，反之则不太可能您连接到的其他非 MQ TLS 服务器将信任其他公司的 CA。由于 JSSE return 只有远程服务器信任的证书，因此它们不应相互影响。您只需要将 MQ 证书添加到您现有的密钥库。
RFC 5246 相关部分的引述位于此 post 的底部。
@a_cornish_pasty 回答你的问题“”也是一个替代方案，因为它允许你指定一个与 Wildfly 的其余部分使用的不同的密钥存储，这个密钥存储可以有仅 MQ 证书，因此不会导致现有密钥库和证书出现问题。
RFC 5246 Section 7.4.4 声明如下：
7.4.4. Certificate Request
When this message will be sent:
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
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 Section 7.4.6 陈述如下：
7.4.6. Client Certificate
When this message will be sent:
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.
然后继续说明：
- 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 8.x。我们的应用程序是 WildFly 9 上的 Java EE 应用程序 运行，它使用与 EAR 文件一起部署在同一 AS 中的资源适配器 (wmq.jmsra.rar)。我们在两个方向上都与 MQ 服务器交互。所以我们一方面有一些 MDB（由于历史起源仍然是 EJB 2.x 格式，没有注释）列出一些队列，它们由 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>
OP 在评论中指出他们使用 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 客户端仅 return 一个适合的证书，该证书基于服务器发送“可接受的可分辨名称列表 [X501] certificate_authorities，以 DER 编码格式表示。"，这意味着如果您的 keyStore 中用于不同用途的证书（例如：现有的非 MQ 证书和 MQ 证书）是 not 由同一个 CA 链签名，并且您连接到的各种 TLS 服务器不接受来自密钥库中其他证书的 CA 的证书（例如：现有的非 MQ 证书和 MQ 证书）然后JSSE 将为每个 return 适当的证书。
例如，如果现有的非 MQ 证书由内部 CA 签署，而 MQ 证书由另一家公司的 CA 签署，则 MQ 公司极不可能信任您的内部 CA 证书，反之则不太可能您连接到的其他非 MQ TLS 服务器将信任其他公司的 CA。由于 JSSE return 只有远程服务器信任的证书，因此它们不应相互影响。您只需要将 MQ 证书添加到您现有的密钥库。
RFC 5246 相关部分的引述位于此 post 的底部。
@a_cornish_pasty 回答你的问题“
RFC 5246 Section 7.4.4 声明如下：
7.4.4. Certificate Request
When this message will be sent:
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
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 Section 7.4.6 陈述如下：
7.4.6. Client Certificate
When this message will be sent:
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.
然后继续说明：
- 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.