Клиент MQ (amqputc) получает сообщение «MQCONNX завершен с кодом причины 2393» при подключении очереди с включенным TLS

Хочу проверить, что не так с моей конфигурацией.

  1. Установил MQ и создал очередь с помощью mq-dev-config.mqsc.

  2. создал корневой, серверный и клиентский сертификат для включения TLS.

  3. Я использую канал DEV.APP.SVRCONN.

  4. Создал сертификаты в папке /var/mqm/qmgrs/QM1/ssl и добавил в него все три сертификата (серверный, клиентский и корневой).

  5. После перезапуска администратор очередей выбирает местоположение, и я вижу, что SSLKEYR(/var/mqm/qmgrs/QM1/ssl/key) и CERTLABL(ibmwebspheremqqm1) указывают правильно.

  6. ниже представлены изменения на стороне канала

    • Изменен DEV.APP.SVRCONN для использования SSLCIPH(ANY_TLS12) SSLCAUTH(ОПЦИОНАЛЬНО) CERTLABL('')
    • удален CONNAUTH в диспетчере очередей
    • Добавлено правило аутентификации резервного канала.
    • Разрешить соединение, если оно соответствует (SSLPEER('CN=mqclient,O=mq,C=us') SSLCERTI('CN=ca-rootca'))
  7. Я могу подключить очередь с помощью Java-клиента.

  8. При использовании amqputc я получаю сообщение об ошибке

    AMQ9636E: Отличительное имя SSL не соответствует имени однорангового узла, канал 'DEV.APP.SVRCONN'

Файл CCDT, файл mqclient.ini, настройки канала CHLAUTH показаны на снимке экрана ниже:

Куда вы поместили файл kdb на стороне клиента? Какую метку вы дали сертификату клиента в базе данных клиента? Как вы сообщаете amqsputc подробности подключения?

JoshMc 06.09.2024 05:25

Я добавил клиентскую базу данных на сервер mq, но в другом месте. я вызываю клиента, используя отдельного пользователя -> Добавлено «SecurityPolicy=UserExternal» в qm.ini и также авторизую этого пользователя.

user10820864 06.09.2024 05:57

Сообщение об ошибке AMQ9639E содержит немного больше информации. Не могли бы вы отредактировать свой вопрос и включить также полный раздел ОБЪЯСНЕНИЯ. Тогда мы сможем увидеть, что и чему соответствует.

Morag Hughson 06.09.2024 06:03

Какую метку вы дали сертификату клиента в базе данных клиента? Как вы сообщаете amqsputc детали соединения и расположение клиентской базы данных?

JoshMc 06.09.2024 06:20

в клиентской базе данных метка — ibmwebspheremqapp. при вызове я использую «export MQCERTLABL=ibmwebspheremqapp». Также amqssslc работает нормально.

user10820864 06.09.2024 06:37

Похоже, что ответ на вопрос, который я задал дважды, на который вы не ответили, заключается в том, что вы используете переменную среды MQSERVER для указания деталей подключения к amqputc. Вы не можете указать шифр с помощью MQSERVER, вам нужно будет использовать таблицу каналов, если вы хотите, чтобы amqputc использовал канал TLS.

JoshMc 06.09.2024 18:21

Привет @Morag, я получаю следующую ошибку. ссылка

user10820864 06.09.2024 22:12

Привет @Joshc, я передаю mqclient_cert.ini через переменную среды MQCLNTCF. В mqclient_cert.ini я передаю путь к файлу CCDT, где у меня определены имя_сертификата, шифрСпецификация и метка сертификата. В mqclient_cert.ini у меня определено местоположение SSLKeyRepository для файла key.kdb. Он может прочитать местоположение, но по какой-то причине читает только неправильный сертификат.

user10820864 06.09.2024 22:16

Согласно сообщению об ошибке, CN=mqserver — это DN сертификата, который не соответствует установленному вами CN=mqclient.

Morag Hughson 06.09.2024 23:53

Привет @Morag, вот почему я не уверен, почему выбран mqserver? я отправляю «certificatePeerName»: «CN=mqclient,O=mq,C=us» в свой файл ccdt.

user10820864 07.09.2024 00:06

Пожалуйста, обновите вопрос содержимым вашего файла CCDT. Ваш последний комментарий предполагает, что вы закодировали определение канала на стороне клиента с DN сертификата на стороне клиента, поэтому оно не совпадает. Я напишу ответ, чтобы полностью объяснить, но был бы признателен за обновление вопроса, поэтому я уверен в том, что вы делаете.

Morag Hughson 07.09.2024 05:18

Спасибо @Morag. Я добавил скриншоты файла CCDT и mqclient.ini по ссылке

user10820864 07.09.2024 06:07

Хорошо, я вижу, что ваш CCDT закодировал certificatePeerName: CN=server, но, как сказано в сообщении об ошибке, администратор очередей представил сертификат с CN=mqserver. Они не совпадают и поэтому канал не запускается.

Morag Hughson 07.09.2024 06:10
Как включить TLS в gRPC-клиенте и сервере : 2
Как включить TLS в gRPC-клиенте и сервере : 2
Здравствуйте! 🙏🏻 Надеюсь, у вас все хорошо и добро пожаловать в мой блог.
Обновление драйверов Microsoft ODBC (с 17 до 18) для PHP
Обновление драйверов Microsoft ODBC (с 17 до 18) для PHP
Все знают, что PHP v7.4 потерял поддержку, и наши недавние старые приложения должны обновиться до PHP v8.x. ...
0
13
61
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

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

При подключении клиентского приложения MQ, например. amqsputc, для администратора очередей, использующего взаимный TLS, на каждом конце есть сертификат, и на каждом конце может быть проверка имени однорангового узла.

Проверка имени однорангового узла — это когда вы предоставляете шаблон для сопоставления с отличительным именем (DN) сертификата, чтобы убедиться, что вы действительно общаетесь с правильным объектом. Хотя может быть предоставлен действительный сертификат, вы можете пойти еще дальше и убедиться, что этот сертификат идентифицирует правильный объект.

Сторона администратора очередей

Чтобы администратор очередей на конце канала проверял DN сертификата клиента, вы указываете этот шаблон либо в определении канала SVRCONN, либо в правиле CHLAUTH (предпочтительно).

Итак, если предположить, что DN сертификата клиента равен CN=mqclient, мы можем представить себе правило CHLAUTH примерно так:

SET CHLAUTH(DEV.APP.SVRCONN) TYPE(SSLPEERMAP) +
    SSLPEER('CN=mqclient') +
    USERSRC(MAP) MCAUSER('clntusr') 

Если клиент представил диспетчеру очередей сертификат с DN, содержащим CN=mqclient, то ему будет разрешен запуск, и ему будет назначен запуск с идентификатором пользователя clntusr.

Клиентская часть

Чтобы клиентская сторона канала проверяла DN сертификата администратора очередей, вы указываете этот шаблон в определении CLNTCONN в CCDT.

Итак, если предположить, что DN сертификата администратора очередей равен CN=mqserver, мы можем представить себе определение CLNTCONN примерно так:

DEFINE CHANNEL(DEV.APP.SVRCONN) CHLTYPE(CLNTCONN) +
       CONNAME('edx2(1414)') SSLCIPH(ANY_TLS12) +
       SSLPEER('CN=mqserver')

Если администратор очередей предоставил клиенту сертификат с DN, содержащим CN=mqserver, то соединение будет разрешено.

Однако если вы перепутаете их и, скажем, закодируете SSLPEER('CN=mqclient') в CCDT на стороне клиента, то совпадение не удастся, и будет выдано сообщение об ошибке AMQ9636E.

Если они просто не совпадают, потому что вы закодировали SSLPEER('CN=server') в CCDT на стороне клиента, а администратор очередей представил сертификат с DN, содержащим CN=mqserver, то также будет выдано сообщение об ошибке AMQ9636E.

ты лучший. «CN=server» — опечатка. Изначально я пробовал «CN=mqclient» и получал эту ошибку. После простого изменения сертификатаPeerName на «CN=mqserver» он начал работать. Большое спасибо.

user10820864 07.09.2024 14:51

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