Хочу проверить, что не так с моей конфигурацией.
Установил MQ и создал очередь с помощью mq-dev-config.mqsc.
создал корневой, серверный и клиентский сертификат для включения TLS.
Я использую канал DEV.APP.SVRCONN.
Создал сертификаты в папке /var/mqm/qmgrs/QM1/ssl и добавил в него все три сертификата (серверный, клиентский и корневой).
После перезапуска администратор очередей выбирает местоположение, и я вижу, что SSLKEYR(/var/mqm/qmgrs/QM1/ssl/key) и CERTLABL(ibmwebspheremqqm1) указывают правильно.
ниже представлены изменения на стороне канала
Я могу подключить очередь с помощью Java-клиента.
При использовании amqputc я получаю сообщение об ошибке
AMQ9636E: Отличительное имя SSL не соответствует имени однорангового узла, канал 'DEV.APP.SVRCONN'
Файл CCDT, файл mqclient.ini, настройки канала CHLAUTH показаны на снимке экрана ниже:
Я добавил клиентскую базу данных на сервер mq, но в другом месте. я вызываю клиента, используя отдельного пользователя -> Добавлено «SecurityPolicy=UserExternal» в qm.ini и также авторизую этого пользователя.
Сообщение об ошибке AMQ9639E содержит немного больше информации. Не могли бы вы отредактировать свой вопрос и включить также полный раздел ОБЪЯСНЕНИЯ. Тогда мы сможем увидеть, что и чему соответствует.
Какую метку вы дали сертификату клиента в базе данных клиента? Как вы сообщаете amqsputc детали соединения и расположение клиентской базы данных?
в клиентской базе данных метка — ibmwebspheremqapp. при вызове я использую «export MQCERTLABL=ibmwebspheremqapp». Также amqssslc работает нормально.
Похоже, что ответ на вопрос, который я задал дважды, на который вы не ответили, заключается в том, что вы используете переменную среды MQSERVER для указания деталей подключения к amqputc. Вы не можете указать шифр с помощью MQSERVER, вам нужно будет использовать таблицу каналов, если вы хотите, чтобы amqputc использовал канал TLS.
Привет @Morag, я получаю следующую ошибку. ссылка
Привет @Joshc, я передаю mqclient_cert.ini через переменную среды MQCLNTCF. В mqclient_cert.ini я передаю путь к файлу CCDT, где у меня определены имя_сертификата, шифрСпецификация и метка сертификата. В mqclient_cert.ini у меня определено местоположение SSLKeyRepository для файла key.kdb. Он может прочитать местоположение, но по какой-то причине читает только неправильный сертификат.
Согласно сообщению об ошибке, CN=mqserver — это DN сертификата, который не соответствует установленному вами CN=mqclient.
Привет @Morag, вот почему я не уверен, почему выбран mqserver? я отправляю «certificatePeerName»: «CN=mqclient,O=mq,C=us» в свой файл ccdt.
Пожалуйста, обновите вопрос содержимым вашего файла CCDT. Ваш последний комментарий предполагает, что вы закодировали определение канала на стороне клиента с DN сертификата на стороне клиента, поэтому оно не совпадает. Я напишу ответ, чтобы полностью объяснить, но был бы признателен за обновление вопроса, поэтому я уверен в том, что вы делаете.
Спасибо @Morag. Я добавил скриншоты файла CCDT и mqclient.ini по ссылке
Хорошо, я вижу, что ваш CCDT закодировал certificatePeerName: CN=server, но, как сказано в сообщении об ошибке, администратор очередей представил сертификат с CN=mqserver. Они не совпадают и поэтому канал не запускается.
При подключении клиентского приложения 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» он начал работать. Большое спасибо.
Куда вы поместили файл kdb на стороне клиента? Какую метку вы дали сертификату клиента в базе данных клиента? Как вы сообщаете amqsputc подробности подключения?