Подключение к каналу mq с помощью java-клиента: ошибка certlabl

Я работаю над микросервисом на Java для подключения к IBM Websphere MQ V8.0 через SSL. Однако в журналах я вижу эту ошибку:

JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2059' ('MQRC_Q_MGR_NOT_AVAILABLE')

В конце MQ ошибка CSQX673E, и причина:

The SSL or TLS channel's channel-name is configured to use certificate label: cert-label. However, the remote peer did not send the necessary information to allow the local channel to use the correct certificate. The remote host is conn-id.

Может кто-нибудь, дайте мне знать, как передать этот параметр, используя Java.

Насколько я понимаю, CERTLABL не является частью сертификата.

Это невозможно, классы IBM MQ для Java и IBM MQ для JMS не поддерживают функцию SNI TLS, которая позволяет им отправлять имя канала во время согласования TLS. Вам нужно будет подключиться к каналу в диспетчере очередей, который использует сертификат по умолчанию диспетчера очередей.

JoshMc 10.08.2018 16:28

Спасибо. Даже Java 8 или Java 9 этого не поддерживает. Клиентские классы MQ для MQ версии 8.0 написаны на Java 7? Также считаю, что Java 8 поддерживает SNI.

djhi89 12.08.2018 15:07
0
2
1 002
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Обратите внимание, что приведенная ниже информация точно так же задокументирована в центрах знаний MQ v8.0.0, v9.0.0 и v9.1.0.


Документы IBM, которые в Страница центра знаний IBM MQ 8.0.0 IBM MQ> Безопасность> Обзор безопасности> Механизмы безопасности IBM MQ> Протоколы безопасности в IBM MQ> Репозиторий ключей SSL или TLS> Метки цифровых сертификатов, понимание требований следующая:

IBM MQ Version 8.0 supports the use of multiple certificates on the same queue manager, using a per-channel certificate label attribute. Inbound channels to the queue manager (for example, server connection or receiver) rely on detecting the channel name using TLS Server Name Indication (SNI), in order to present the correct certificate from the queue manager.

Эта же страница также документирует это:

Note that inbound channels (including receiver, cluster-receiver, unqualified server, and server-connection channels) only send the configured certificate if the IBM MQ version of the remote peer fully supports certificate label configuration, and the channel is using a TLS CipherSpec.

In all other cases, the queue manager CERTLABL parameter determines the certificate sent. In particular, the following only ever receive the certificate configured by the CERTLABL parameter of the queue manager, regardless of the channel-specific label setting:

  • All current Java and JMS clients.
  • Versions of IBM MQ prior to Version 8.0.

IBM также документирует аналогичную информацию на странице IBM MQ> Справочник> Справочник по конфигурации> Атрибуты канала> Атрибуты каналов в алфавитном порядке> Метка сертификата (CERTLABL) центра знаний IBM MQ 8.0.0:

Inbound channels (including RCVR, CLUSRCVR, unqualified SERVER, and SVRCONN channels) will only send the configured certificate if the IBM® MQ version of the remote peer fully supports certificate label configuration and the channel is using a TLS CipherSpec. If that is not the case, the queue manager CERTLABL attribute determines the certificate sent. This restriction is because the certificate label selection mechanism for inbound channels depends upon a TLS protocol extension that is not supported in all cases. In particular, Java™ clients, JMS clients, and all versions of IBM MQ prior to Version 8.0 do not support the required protocol extension and will only ever receive the certificate configured by the queue manager CERTLABL attribute, regardless of the channel-specific label setting.


Как вы заявили, Java 8 поддерживает SNI, но очевидно, что IBM еще не реализовала эту функцию в классах IBM MQ для Java или IBM MQ Classes для JMS.

Одно из возможных решений, которое я могу придумать, заключается в том, что вы можете выяснить, какая базовая функция вызывает MQ для создания сеанса TLS, и переопределить это, чтобы установить для атрибута SNI значение, которое MQ распознает в диспетчере очереди, с помощью кода, подобного следующему:

SSLParameters params = sslSocket.getSSLParameters();
params.setServerNames(serverNames);
sslSocket.setSSLParameters(params);

IBM задокументировала формат передачи имени канала в SNI в Technote "IBM WebSphere MQ: как MQ предоставляет возможность использования нескольких сертификатов (CERTLABL)":

The SNI address used by MQ is based upon the channel name that is being requested, followed by a suffix of ".chl.mq.ibm.com".

MQ channel names are mapped to be valid SNI names as follows:

  • Upper case letters A-Z are folded to lower case
  • Digits 0 through 9 are left unchanged
  • All other characters including lower-case letters a-z are converted into their 2-digit hexadecimal ASCII character code followed by a hyphen.
  • lower case letters a through z map to "61-" through "7a-" respectively
  • percent (%) maps to "25-"
  • hyphen (-) maps to "2d-"
  • dot (.) maps to "2e-"
  • forward slash (/) maps to "2f-"
  • underscore (_) maps to "5f-"

On EBCDIC platforms, the channel name is converted to ASCII before this mapping is applied. As an example, channel name "TO.QMGR1" maps to an SNI address of "to2e-qmgr1.chl.mq.ibm.com".

By contrast, the lower case channel name "to.qmgr1" maps onto SNI address of "74-6f-2e-71-6d-67-72-1.chl.mq.ibm.com".

Привет, Джош! Не могли бы вы представить доказательства в поддержку этого утверждения: «IBM еще не реализовала эту функцию в классах IBM MQ для Java или IBM MQ Classes для JMS». Это действительно помогло бы мне прийти к выводу

djhi89 17.08.2018 08:18

@ djhi89 прямо над моим утверждением - это цитата из документа IBM MQ, где я выделил жирным шрифтом утверждение, в котором прямо говорится, что клиенты Java ™, клиенты JMS не поддерживают необходимое расширение протокола для получения сертификата для конкретного канала.

JoshMc 17.08.2018 08:45

@ djhi89 вы также наблюдали поведение из первых рук, как описано в вашем вопросе.

JoshMc 17.08.2018 08:57

@JoshMc У меня такая же проблема, и я вообще не понимаю этого ответа. На стороне MQ у меня есть два частных сертификата в хранилище ключей, а у клиентов есть открытые части сертификатов в их хранилище доверенных сертификатов. С CERTLBL на qm все работает с обоими сертификатами. Но в тот момент, когда я переопределяю qm CERTLBL с атрибутом CERTLBL на канале, ни один клиент не может подключиться с ошибкой AMQ9673: канал «XXX» не отправил правильный сертификат удаленному узлу. Эта ошибка не имеет смысла, поскольку в документации указано, что канал CERTLBL используется для переопределения атрибута qm CERTLBL. Дополнительная аутентификация, MQ 9.0.5.0, AIX

Talijanac 12.08.2020 13:13

@Talijanac - это клиенты на основе Java?

JoshMc 12.08.2020 16:19

Мой ответ относится к клиентам Java / JMS API. Они не предоставляют SNI, поэтому функция метки сертификата не работает с ними на v8.0 / 9.0 LTS / 9.0 CD / 9.1 LTS. В документации для компакт-диска IBM MQ 9.1 есть старые ссылки, но насколько я могу судить, похоже, что IBM добавила SNI для клиентов Java и JMS API в выпуске компакт-диска 9.1.1, и он включен в 9.2. Я отправляю обратную связь в IBM на страницах KC, которые кажутся устаревшими.

JoshMc 13.08.2020 02:16

@JoshMC Спасибо за ответ. Думаю, я разобрался. Когда CERTLABL используется на приемном канале, это всегда приводит к ошибке AMQ9673. Неважно, действительные сертификаты или нет. Эта функция НЕ является «альтернативным» сертификатом сервера для MQ. Мое желание состояло в том, чтобы выпустить новый самозаверяющий сертификат сервера, но без принуждения клиентов к немедленному обновлению своих доверенных лиц новым сертификатом. Вместо этого я хотел предоставить им альтернативный канал, на который они могут перейти, когда они будут готовы.

Talijanac 01.09.2020 14:36

Как ни странно, CERTLABL - это функция вызова канала. Вам следует настроить CERTLABL на вызывающий канал, который затем «запрашивает» у MQ-сервера замену сертификата на желаемый сертификат. Таким образом, эту функцию можно использовать только при обмене данными MQ-MQ.

Talijanac 01.09.2020 14:37

Я экспериментировал с Java-клиентами, автономными приложениями и WebSphere AS. Но мне также это нужно для работы с клиентами .NET и C.

Talijanac 01.09.2020 14:39

@Talijanac Он работает как на клиентах, так и на серверах, соединяя каналы и каналы приема. Но клиенты на базе java не поддерживают его до 9.1.1 или 9.2.0.0. То, что вы описываете, должно работать, если клиент это поддерживает. Клиенты .net и c должны его поддерживать.

JoshMc 01.09.2020 16:22

Другие вопросы по теме