Подключение к WebSphere MQ с использованием анонимного SSL

Чтобы удовлетворить ваше требование не аутентифицировать клиентскую сторону, канал должен быть установлен на SSLCAUTH(OPTIONAL). У администратора очередей должен быть сертификат, а у клиента должно быть хранилище trsuststore, содержащее цепочку подписавших для сертификата QMgr (если он подписан CA) или открытый ключ сертификата QMgr (если он подписан самостоятельно). Помните, что при использовании SSL/TLS сторона сервера всегда аутентифицируется, и для этого требуется личный сертификат на сервере и способ его проверки клиентом. Кроме того, клиент и QMgr должны согласовать используемые протоколы, и если требуется FIPS, они должны использовать один из алгоритмов, сертифицированных FIPS.

В коде, опубликованном выше, есть одна вещь, которая определенно неверна, и несколько вещей, которые являются вторичными возможными причинами проблемы. Как только вы разрешите конфигурацию, которую я опишу ниже, вы можете столкнуться с одной из второстепенных проблем. Чтобы быть уверенным, что из этого применимо, необходимо знать, какая версия клиента и сервера WMQ, определение канала, настройки SSL для вызова JSSE и/или командной строки и т. д.

Таким образом, в этом случае 2393 указывает, что клиентская сторона не может инициализировать сеанс SSL/TLS. Очевидная проблема заключается в том, что, согласно странице Инфоцентра SSL CipherSpecs and CipherSuites, эти два параметра являются недопустимой комбинацией:

MQEnvironment.sslFipsRequired=true;
MQEnvironment.sslCipherSuite = "SSL_RSA_WITH_RC4_128_MD5";//RC4_MD5_US

Вы не указали, какая у вас версия клиента и сервера WMQ, поэтому вот ссылка на эту страницу для V7.0, V7.1 и V7.5. Обратите внимание, что столбец, в котором указано соответствие FIPS, не включает набор шифров MD5. (MD5 не работает и не должен использоваться для подписи сертификатов, SSL, TLS или чего-то еще. Если на то пошло, SSL не работает, и в дальнейшем следует использовать только шифры TLS, но это обсуждение для другого вопроса.) Чтобы получить это вам нужно либо установить MQEnvironment.sslFipsRequired=false, либо выбрать один из наборов шифров, который сертифицирован и указан в крайнем правом столбце.

Не зная, с какими версиями вы работаете, я бы посоветовал установить для FIPS значение false и использовать NULL_SHA в канале и SSL_RSA_WITH_NULL_SHA в приложении, пока вы не убедитесь, что все остальные конфигурации работают. Этот набор шифров доступен на всех платформах во всех версиях WMQ. Использование этого для проверки гарантирует, что все остальные настройки верны. Как только вы заработаете, выберите более надежный набор шифров на основе TLS и SHA, доступный как на стороне сервера, так и на стороне клиента.

Тем не менее, вот некоторые из других возможных проблем, с которыми вы можете столкнуться.

Вы можете получить 2393, когда приложение не находит свое хранилище доверенных сертификатов или цепочку сертификатов или подписантов в этом хранилище доверенных сертификатов, которое представляет серверную часть. Вы можете передать их в командной строке:

java -Djavax.net.ssl.trustStore=key2.jks \
     -Djavax.net.ssl.trustStorePassword=passw0rd \
     -cp "%CLASSPATH%"  \
     com.ibm.examples.JMSDemo -pub -topic JMSDEMOPubTopic

Операции с хранилищем ключей и хранилищем доверенных сертификатов обрабатываются поставщиком JSSE, а не самим WMQ. Поэтому любой метод, который вы обычно используете для настройки поставщика JSSE, должен работать. В дополнение к командной строке, как показано выше, это может включать, например, настройки, управляемые контейнером, на сервере Java EE.

Вы также можете получить сообщение об ошибке (я не помню, было ли это 2393), если соединение доходит до сервера, представляющего свой сертификат, а хранилище доверенных сертификатов имеет неправильную или неполную цепочку подписантов.

Другие возможные причины ошибки 2393 включают права доступа к файлам, неправильное написание пути или имени файла и т. д.