Поработав некоторое время, я смог решить эту проблему.С самого начала у меня была эта проблема конфигурации сертификата на стороне приложения.Даже после создания self-signed сертификата, помеченного после ibmwebspheremq<queue_manager_name> и совместного использования извлеченных сертификатов с клиентским приложением с помощью инструмента ikeyman, произошло AMQ9637E: Channel is lacking a certificate..
В двух словах, чтобы полностью решить эту проблему, я сделалследующее:
Обновите зависимость MQ клиента до com.ibm.mq.allclient:v9.1.2.0.Если вы используете maven, используйте следующую зависимость ( MQC91: IBM MQ Clients ).
<dependency>
<groupId>com.ibm.mq</groupId>
<artifactId>com.ibm.mq.allclient</artifactId>
<version>9.1.2.0</version>
</dependency>
Теперь, если приложение работает на Oracle JVM, мы должны убедить MQ-клиентlib для использования имен комплектов шифров Oracle JVM.Для этого либо добавьте -Dcom.ibm.mq.cfg.useIBMCipherMappings=false в качестве флага JVM, либо добавьте System.setProperty("com.ibm.mq.cfg.useIBMCipherMappings", "false") в качестве системного свойства.
Выберите подходящий набор шифров для связи с MQ.Этот документ TLS CipherSpecs и CipherSuites в классах IBM MQ для JMS будет полезен, поскольку IBM имеет устаревшее число слабых спецификаций шифров IBMMQ 9 и более поздних версий.
Я бы предложил использовать ECDHE_* спецификации шифров, поскольку они предоставляют Эфемерные ключи для поддержания Прямой секретности .
Затем, используя инструмент ikeyman GUI, я создал сертификат self-signed, помеченный именем ibmwebspheremq<queue_manager_name>, и вместо извлечения файла .arm я экспортирую сертификат как файлы .jks.Файлы keystore.jks и truststore.jks экспортированы из одного сертификата.После этого подключите их к приложению с помощью системных свойств;
System.setProperty("javax.net.ssl.trustStore", "truststore.jks");
System.setProperty("javax.net.ssl.trustStorePassword", "<password>");
System.setProperty("javax.net.ssl.keyStore", "keystore.jks");
System.setProperty("javax.net.ssl.keyStorePassword", "<password>");
В этой конфигурации проблема рукопожатия SSL исчезла, но IBM MQ все еще запрашивал аутентификацию пользователя с использованием имени пользователя и пароля.Чтобы предоставить их, следует добавить эти свойства в MQEnvironment,
MQEnvironment.properties.put(com.ibm.mq.constants.CMQC.USER_ID_PROPERTY, "<user_name>");
MQEnvironment.properties.put(com.ibm.mq.constants.CMQC.PASSWORD_PROPERTY, "<password>");
. В моем случае эти учетные данные были системными учетными данными.
Если вы просто хотите пропустить проверку подлинности пользователя следующим образом,вы можете обновить конфигурацию IBMMQ, чтобы пропустить проверку учетных данных, используя runmqsc CLI-инструмент, подобный этому (см. Включение аутентификации соединения в администраторе очередей документ),
ALTER QMGR CONNAUTH(USE.PW)
DEFINE AUTHINFO(USE.PW) +
AUTHTYPE(IDPWOS) +
FAILDLAY(10) +
CHCKLOCL(OPTIONAL) +
CHCKCLNT(OPTIONAL)
REFRESH SECURITY TYPE(CONNAUTH)
Обратите внимание, что CHCKCLNT значение необходимо установить как OPTIONAL, чтобы игнорировать проверку учетных данных пользователя клиента.IBM MQ должен начать работать с клиентским приложением, когда SSL включен после этих конфигураций.
Спасибо @JoshMc за поддержку в решении этой проблемы.