Создание хранилища сертификатов для IIB

По умолчанию, IIB в качестве truststore хранилища ключей использует файл cacerts в формате Java keystore (JKS), который расположен в директории /opt/ibm/mqsi/version/jre17/lib/security/.

Так как файл cacerts является частью установки IIB, то он может быть изменен после обновления (установка fix pack) или переустановки IIB. Поэтому лучше не использовать это хранилище ключей, а создать другое, в отдельном файле и другом расположении (не /opt/ibm/mqsi…).

Так же лучше использовать для truststore и keystore отдельные файлы хранилища и различные директории, чтобы обезопасить приватные ключи. Например, /var/mqsi/security/certificates/ – для truststore, и /var/mqsi/security/keys – для keystore.

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

Далее мы рассмотрим как создать truststore-хранилище и переключить IIB на его использование.

Для создания нового хранилища можно воспользоваться утилитой ikeycmd:

Эта команда, в директории /var/mqsi/security/certificates, создаст файл хранилища IIBtruststore.jks с типом .jks, паролем password и наполнит его CA-сертификатами, поставляемыми вместе с продуктом (Обычно это корневые сертификаты Entrust, Thawte, Verisign).

Основные утилиты для работы с хранилищами ключей, ikeyman, ikeycmd и ikeytool расположены в директории /opt/ibm/mqsi/version/jre17/bin/.

Для того, что бы IIB стал использовать созданный нами truststore, необходимо выполнить следующие команды.

Устанавливаем truststore для IIB:

Устанавливаем пароль для truststore:

Параметр -u задает user ID, который может быть любым, он не нужен для доступа к хранилищу.

После этого требуется перезапустить узел интеграции что бы изменения вступили в силу. Рассмотрим еще пару полезных команд по этой теме.

Изменить пароль можно следующей командой:

Посмотреть все текущие настройки BrokerRegistry (например, что бы узнать расположение используемого truststore):

Результат команды:

Выгрузить всю цепочку сертификатов в файл, используя openssl:

Полезные ссылки по теме:

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
Метки: , , ,
Опубликовано в WebSphere Message Broker, Тюнинг
4 комментария на “Создание хранилища сертификатов для IIB
  1. LordHydra:

    Парни, пропущено 2 команды, указания объектов паролей для кейстора и трастора. Вы указали только команду указания пути к хранилищу. Ваш пример это одно хранилище для всего брокера, хорошая практика использовать сепарированный SSL на группах исполнения.

    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
    • Sergey Kirsanov Sergey Kirsanov:

      Спасибо за комментарий, но:
      1. В данном посте более детально рассмотрено создание truststore (хотя keystore создается аналогично) и указана команда для установки пароля для truststore:

      mqsisetdbparms integrationNodeName -n brokerTruststore::password -u ignore -p password

      Все на месте.
      2. По поводу “хорошая практика использовать сепарированный SSL на группах исполнения” – кто сказал и почему?
      На мой взгляд, это зависит от конкретных целей и архитектуры контура IIB.
      Например, мы, устанавливая truststore на уровне узла интеграции, преследуем две цели: простое вертикальное масштабирование серверов интеграции и легкий перенос приложений из одного сервера интеграции в другой, без дополнительных настроек.

      VN:F [1.9.22_1171]
      Rating: 0 (from 0 votes)
  2. LordHydra:

    Плюсов использования SSL на уровне EG множество.
    Использование 1 SSL конфигурации глобально на 1 брокер это “для ленивых” решение не гибкое.
    Допустим плюсы которые сходу видны:
    – если взаимодействий куча можно выдавать разные клиентские/серверные сертификаты по разным взаимодействиям.
    – перенастройка SSL требует рестарт конкретной группы, но не брокера.
    – в случае SSL ошибок они будут видны по конкретной группе, по которой можно включать SSL debug.
    – По разным группам есть возможность использовать разные настройки HTTPSConnector’a, если необходимо.
    – Возможность поднимать разные порты для разных сервисов шины, а не вешать все сервисы шины на 1 brokerwide листенерс разными URI.
    – Если порты для взаимодействий на брокере разные тех работы можно проводить на конкретных адаптерах чуть проще.

    Можно в целом пойти и дальше.
    В общем глобальный SSL на брокере это в моих глазах для каких то простых решений в целом.

    В плане масштабирования у нас масштабируются физические сервера, а не группы исполнения на одном брокере.

    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
    • Sergey Kirsanov Sergey Kirsanov:

      Использование единого truststore глобально на узел интеграции это не для ленивых, а для хитрых!
      Ничто не мешает использовать один truststore для всего узла интеграции, при этом используя HTTP-листнеры на серверах интеграции (Integration server (embedded) listeners).
      И все плюсы, что вы перечислили, будут работать и здесь, т.е. можно использовать разные порты, настройки HTTP(S)Connector’a и сертификаты для разных серверов интеграции, а при перенастрйке требуется перезапуск только конкретного сервера интеграции.

      VN:F [1.9.22_1171]
      Rating: 0 (from 0 votes)

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Выбор языка: