来自 Mule 的 IBM MQ 连接问题 - UNSUPPORTED_CIPHER_SUITE 并且没有 mqjbnd 错误

Question

我正在尝试以客户端模式从 mule 连接 MQ。可以连接，没有问题。

但是当我使用密码套件“TLS_RSA_WITH_AES_128_CBC_SHA”启用 SSL 时，遇到错误为 UNSUPPORTED_CIPHER_SUITE，因此根据 IBM 技术说明启用了 MQ 跟踪器，现在我在 java.library.path 中没有收到 mqjbnd 错误。

代码sn-p:-

<spring:bean id="ConnectionFactory" name="ConnectionFactory" class="com.ibm.mq.jms.MQConnectionFactory">
     <spring:property name="hostName" value="xxxx" />
     <spring:property name="port" value="xxxx"/>
     <spring:property name="queueManager" value="xxxx"/>
     <spring:property name="transportType" value="1"/>
     <spring:property name="sSLCipherSuite" value="TLS_RSA_WITH_AES_128_CBC_SHA"/>
     <spring:property name="channel" value="xxxx"/>
</spring:bean>

<jms:connector name="JMS" username="xxxx" password="xxxx" specification="1.1" connectionFactory-ref="ConnectionFactory" numberOfConsumers="1" validateConnections="true"  persistentDelivery="true" doc:name="JMS"/>

错误 -

org.mule.module.launcher.DeploymentStartException: MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2400' ('MQRC_UNSUPPORTED_CIPHER_SUITE').
        at org.mule.module.launcher.application.DefaultMuleApplication.start(DefaultMuleApplication.java:178) ~[mule-module-launcher-3.9.0.jar:3.9.0]
        at org.mule.module.launcher.artifact.ArtifactWrapper$4.execute(ArtifactWrapper.java:106) ~[mule-module-launcher-3.9.0.jar:3.9.0]
        at org.mule.module.launcher.artifact.ArtifactWrapper.executeWithinArtifactClassLoader(ArtifactWrapper.java:137) ~[mule-module-launcher-3.9.0.jar:3.9.0]
        at org.mule.module.launcher.artifact.ArtifactWrapper.start(ArtifactWrapper.java:101) ~[mule-module-launcher-3.9.0.jar:3.9.0]
        at org.mule.module.launcher.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:73) ~[mule-module-launcher-3.9.0.jar:3.9.0]
        at org.mule.module.launcher.DefaultArchiveDeployer.deployArtifact(DefaultArchiveDeployer.java:536) [mule-module-launcher-3.9.0.jar:3.9.0]
        at org.mule.module.launcher.DefaultArchiveDeployer.deployArtifact(DefaultArchiveDeployer.java:333) [mule-module-launcher-3.9.0.jar:3.9.0]
        at org.mule.module.launcher.DefaultArchiveDeployer.deployExplodedApp(DefaultArchiveDeployer.java:325) [mule-module-launcher-3.9.0.jar:3.9.0]
        at org.mule.module.launcher.DefaultArchiveDeployer.deployExplodedArtifact(DefaultArchiveDeployer.java:100) [mule-module-launcher-3.9.0.jar:3.9.0]
        at org.mule.module.launcher.DeploymentDirectoryWatcher.deployExplodedApps(DeploymentDirectoryWatcher.java:298) [mule-module-launcher-3.9.0.jar:3.9.0]
        at org.mule.module.launcher.DeploymentDirectoryWatcher.start(DeploymentDirectoryWatcher.java:156) [mule-module-launcher-3.9.0.jar:3.9.0]
        at org.mule.module.launcher.MuleDeploymentService.start(MuleDeploymentService.java:139) [mule-module-launcher-3.9.0.jar:3.9.0]
        at org.mule.module.launcher.MuleContainer.start(MuleContainer.java:172) [mule-module-launcher-3.9.0.jar:3.9.0]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_161]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_161]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_161]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_161]
        at org.mule.module.reboot.MuleContainerWrapper.start(MuleContainerWrapper.java:52) [mule-module-reboot-3.9.0.jar:3.9.0]
        at org.tanukisoftware.wrapper.WrapperManager$12.run(WrapperManager.java:2788) [wrapper-3.2.3.jar:3.2.3]
Caused by: org.mule.retry.RetryPolicyExhaustedException: JMSWMQ0018: Failed to connect to queue manager 'XXXX' with connection mode 'Client' and host name 'null'.
        at org.mule.retry.policies.AbstractPolicyTemplate.execute(AbstractPolicyTemplate.java:111) ~[mule-core-3.9.0.jar:3.9.0]
        at org.mule.transport.AbstractConnector.connect(AbstractConnector.java:1658) ~[mule-core-3.9.0.jar:3.9.0]
        at org.mule.transport.jms.JmsConnector.connect(JmsConnector.java:483) ~[mule-transport-jms-3.9.0.jar:3.9.0]
        at org.mule.transport.AbstractConnector.start(AbstractConnector.java:449) ~[mule-core-3.9.0.jar:3.9.0]
        at sun.reflect.GeneratedMethodAccessor36.invoke(Unknown Source) ~[?:?]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_161]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_161]
        at org.mule.lifecycle.phases.DefaultLifecyclePhase.applyLifecycle(DefaultLifecyclePhase.java:230) ~[mule-core-3.9.0.jar:3.9.0]
        at org.mule.lifecycle.RegistryLifecycleCallback.doApplyLifecycle(RegistryLifecycleCallback.java:108) ~[mule-core-3.9.0.jar:3.9.0]
        at org.mule.lifecycle.RegistryLifecycleCallback.onTransition(RegistryLifecycleCallback.java:78) ~[mule-core-3.9.0.jar:3.9.0]
        at org.mule.lifecycle.AbstractLifecycleManager.invokePhase(AbstractLifecycleManager.java:146) ~[mule-core-3.9.0.jar:3.9.0]
        at org.mule.lifecycle.RegistryLifecycleManager.fireLifecycle(RegistryLifecycleManager.java:134) ~[mule-core-3.9.0.jar:3.9.0]
        at org.mule.registry.AbstractRegistryBroker.fireLifecycle(AbstractRegistryBroker.java:88) ~[mule-core-3.9.0.jar:3.9.0]
        at org.mule.registry.MuleRegistryHelper.fireLifecycle(MuleRegistryHelper.java:141) ~[mule-core-3.9.0.jar:3.9.0]
        at org.mule.lifecycle.MuleContextLifecycleManager$MuleContextLifecycleCallback.onTransition(MuleContextLifecycleManager.java:74) ~[mule-core-3.9.0.jar:3.9.0]
        at org.mule.lifecycle.MuleContextLifecycleManager$MuleContextLifecycleCallback.onTransition(MuleContextLifecycleManager.java:70) ~[mule-core-3.9.0.jar:3.9.0]
        at org.mule.lifecycle.AbstractLifecycleManager.invokePhase(AbstractLifecycleManager.java:146) ~[mule-core-3.9.0.jar:3.9.0]
        at org.mule.lifecycle.MuleContextLifecycleManager.fireLifecycle(MuleContextLifecycleManager.java:62) ~[mule-core-3.9.0.jar:3.9.0]
        at org.mule.DefaultMuleContext.start(DefaultMuleContext.java:320) ~[mule-core-3.9.0.jar:3.9.0]

一些注意事项 -

1) 不知道为什么我会收到密码套件错误，因为我能够从具有相同密码的其他 java 程序成功连接到相同的 MQ。

2) 此外，我正在尝试作为客户端 [TransportType=1] 连接，因为它尝试作为绑定而不是客户端连接。

3) 我正在使用 OpenJDK-1.8、MQ-8.0.0.2 服务器并尝试使用 MQ-java 客户端作为 7.5.0.0

4) 我指定了-Dcom.ibm.mq.cfg.useIBMCipherMappings=false

谁能指导我在这里缺少什么。

Answer 1

您可以忽略mqjbnd 错误。 mqjbnd 仅用于与同一服务器上的本地队列管理器的绑定模式连接。当您打开跟踪时，java 客户端将查找此文件以将有关它的信息记录到跟踪文件中。在客户端模式下，它不被使用，所以是一个无害的错误。

APAR IC89380 描述了为什么使用mqjbnd：

| The native library 'mqjbnd' is used by the WebSphere MQ
| classes for Java and WebSphere MQ classes for JMS when
| creating a connection to the queue manager using a 'bindings'
| mode connection. A bindings mode connection is a connection
| which uses the system's memory to communicate with the queue
| manager, as opposed to a 'client' mode connection which uses
| a TCP/IP socket.

---

APAR IV66840，添加了使用非 IBM JRE（即 Oracle/OpenJDK）CipherSuite 名称并添加了useIBMCipherMappings 设置的能力，直到 7.5.0.5 才出现。因为您使用的是 7.5.0.0，所以此设置不会有任何影响。

在 7.5.0.5 之前，您将无法将任何 CipherSuite 与 Oracle/OpenJDK JRE 一起使用，除非它与 IBM JRE 同名。 IBM MQ v8.0.0.3 和更高版本的队列管理器支持的所有 TLSv1.2 CipherSpecs 都具有 CipherSuite，在 Oracle JRE 中以 TLS 为前缀，在 IBM JRE 中以 SSL 为前缀。在 MQ v8.0.0.2 中，队列管理器仍将允许 CipherSpec TLS_RSA_WITH_RC4_128_SHA256 在 IBM 和 Oracle/OpenJDK JRE 中的 CipherSuite 名称为 SSL_RSA_WITH_RC4_128_SHA，但由于在下一个维护级别中不推荐使用它，因此不推荐使用使用它。

---

解决方案，将您的 IBM MQ jar 文件至少升级到以下级别之一：

Version    Maintenance Level
v7.5       7.5.0.5
v8.0       8.0.0.2
v9.0LTS    9.0.0.0
v9.0CD     9.0.1

---

请注意，MQ v7.5 将于 2018 年 4 月 30 日从 IBM 终止服务，因此建议使用 v8.0 或更高版本。