IBM-MQ: настройка взаимной аутентификации TLS между клиентом и администратором очередей - PullRequest
Новая
       19

IBM-MQ: настройка взаимной аутентификации TLS между клиентом и администратором очередей

0 голосов
/ 16 февраля 2020

Я пытаюсь настроить взаимную аутентификацию TLS между клиентом и администратором очередей IBM-MQ (используя ibmcom / mq Docker image ). Сертификаты являются самозаверяющими и создаются в соответствии с этой статьей . Как указано в документах , должна быть возможность запекать закрытый ключ сервера и оба сертификата в образ. Мой Dockerfile выглядит следующим образом: 

FROM ibmcom/mq

USER mqm
COPY --chown=mqm:mqm 20-config.mqsc /etc/mqm/ # creation of additional queues, no problems here
COPY --chown=mqm:mqm keys_mq1/key.key /etc/mqm/pki/keys/mykey/
COPY --chown=mqm:mqm keys_mq1/key.crt /etc/mqm/pki/keys/mykey/
COPY --chown=mqm:mqm keys_client/client.crt /etc/mqm/pki/trust/0/

Файлы можно найти в работающем контейнере: 

/etc/mqm/pki/keys/mykey
drwxr-xr-x 1 mqm mqm 4096 Feb 16 11:18 .
drwxr-xr-x 1 mqm mqm 4096 Feb 16 11:18 ..
-rwxr-xr-x 1 mqm mqm 1253 Feb 16 10:54 key.crt
-rwxr-xr-x 1 mqm mqm 1704 Feb 16 10:53 key.key

/etc/mqm/pki/trust/0
drwxr-xr-x 2 mqm mqm 4096 Feb 16 13:34 .
drwxr-xr-x 3 mqm mqm 4096 Feb 16 13:34 ..
-rwxr-xr-x 1 mqm mqm 1054 Feb 16 13:29 client.crt

Следует отметить, что согласно документам , детали канала теперь должны показывать следующую запись: CERTLABL(mykey). В моем случае это просто CERTLABL( ). Тем не менее, я не уверен, что в этом проблема, аутентификация сервера без аутентификации клиента кажется работающей (см. Ниже). 

DISPLAY CHANNEL(DEV.APP.SVRCONN)
     1 : DISPLAY CHANNEL(DEV.APP.SVRCONN)
AMQ8414I: Display Channel details.
   CHANNEL(DEV.APP.SVRCONN)                CHLTYPE(SVRCONN)
   ALTDATE(2020-02-16)                     ALTTIME(13.34.47)
   CERTLABL( )                             COMPHDR(NONE)
   COMPMSG(NONE)                           DESCR( )
   DISCINT(0)                              HBINT(300)
   KAINT(AUTO)                             MAXINST(999999999)
   MAXINSTC(999999999)                     MAXMSGL(4194304)
   MCAUSER(app)                            MONCHL(QMGR)
   RCVDATA( )                              RCVEXIT( )
   SCYDATA( )                              SCYEXIT( )
   SENDDATA( )                             SENDEXIT( )
   SHARECNV(10)                            SSLCAUTH(OPTIONAL)
   SSLCIPH(ANY_TLS12)                      SSLPEER( )
   TRPTYPE(TCP)

На стороне клиента я создал два Java хранилища ключей (JKS), одно с сертификатом сервера (хранилище доверенных сертификатов) и одно с парой ключей клиента.

Мои попытки подключения были следующими:

  1. Подключение по умолчанию администратор очередей QM1 с использованием предоставленного пользователя app (без пароля) и DEV.APP.SVRCONN канала. Клиентское приложение - это существующий инструмент, который отлично работает с существующей инфраструктурой MQ, я только что обменялся хранилищами ключей и деталями подключения.

Клиентское исключение: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').

MQ log: 

AMQ5534E: User ID 'app' authentication failed
AMQ5542I: The failed authentication check was caused by the queue manager CONNAUTH CHCKCLNT(REQDADM) configuration.
Подключение с использованием предоставленного пользователя admin и канала DEV.ADMIN.SVRCONN через IBM MQ Explorer (в этом сценарии я переключился на admin, поскольку app не имеет достаточных прав для использования с MQ Explorer, независимо от метода аутентификации ). Я установил опцию «без пароля», так как я хочу аутентифицироваться с помощью сертификата клиента.

Сообщение об ошибке MQ Explorer: 

Access not permitted. You are not authorized to perform this operation. (AMQ4036)
  Explanation: The queue manager security mechanism has indicated that the userid associated with this request is not authorized to access the object.

Журнал MQ: 

AMQ5540E: Application 'MQ Explorer 8.0.0' did not supply a user ID and password
AMQ5541I: The failed authentication check was caused by the queue manager CONNAUTH CHCKCLNT(REQDADM) configuration.
AMQ9557E: Queue Manager User ID initialization failed for 'admin'.
То же, что и 2., но без хранилища ключей клиента и предоставления пароля. Works . Идея состояла в том, чтобы проверить, что, по крайней мере, сертификат сервера настроен правильно (с другой стороны, я не уверен, что MQ Explorer принудительно проверяет сертификат сервера в хранилище доверенных сертификатов в первую очередь).

Чего мне не хватает?

edit: моя настоящая цель - использовать взаимную аутентификацию для пользователя app и канала DEV.APP.SVRCONN.

1 Ответ

0 голосов
/ 17 февраля 2020

Атрибут CHANNEL CERTLABL

Этот атрибут устанавливать не нужно, если только вам не нужно представить сертификат для этого SVRCONN, отличный от всех других каналов в администраторе очередей. Если у вас нет этого требования, оставьте CHANNEL attribute CERTLABL пустым и просто используйте общий сертификат администратора очередей. Это либо соответствует шаблону сертификата по умолчанию ibmWebSphereMQ<qm-name>, либо используется метка сертификата, установленная с помощью следующей команды MQS C: 

ALTER QMGR CERTLABL(my-certificate-label)

Аутентификация подключения (встроенная проверка пароля MQ)

В новом администраторе очередей, созданном в версии V8 или выше, будет включена функция аутентификации соединения, что означает, что администратор очередей проверит все пароли, которые вы предоставили, и, что более важно, в вашем сценарии потребует, чтобы любой привилегированный идентификатор пользователя должен поставить один. Сообщение об ошибке, которое вы сообщаете при попытке соединения 1: 

AMQ5542I: The failed authentication check was caused by the queue manager CONNAUTH CHCKCLNT(REQDADM) configuration.

и попытке соединения 2/3: 

AMQ5540E: Application 'MQ Explorer 8.0.0' did not supply a user ID and password
AMQ5541I: The failed authentication check was caused by the queue manager CONNAUTH CHCKCLNT(REQDADM) configuration.

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

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

ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL)

REFRESH SECURITY TYPE(CONNAUTH)

SSL / TLS с взаимной аутентификацией

Чтобы обеспечить взаимную аутентификацию SSL / TLS, в конечном итоге вам потребуется убедиться, что ваш CHANNEL атрибут SSLCAUTH установлен на REQUIRED. Но самый простой способ добиться этого - начать с установки на OPTIONAL и перейти к точке, в которой клиент проверяет подлинность сертификата администратора очередей, а затем заставить его отправлять свою собственную, и, наконец, установить SSLCAUTH(REQUIRED), чтобы убедиться, что он будет работать только в том случае, если клиент продолжит делать это.

Вам необходимо убедиться, что вы установили SSLCIPH на обоих концах канала. Вы не упоминаете об этом в своем вопросе, но в инструкциях, на которые вы ссылаетесь, используется SSLCIPH(ANY_TLS12), поэтому я предполагаю, что вы сделали то же самое.

Если вы успешно установили соединение и не уверены, отправил ли клиент сертификат для администратора очередей, используйте следующую команду MQS C: - 

DISPLAY CHSTATUS(DEV.ADMIN.SVRCONN) SSLPEER SSLCERTI

, чтобы увидеть DN субъекта и DN эмитента сертификата, отправленного клиентом. Если поле пустое, сертификат не отправлен.

...