Конфигурирование подключения по протоколу Secure Sockets Layer в решении WebSphere MQ File Transfer Edition

Решение WebSphere MQ File Transfer Edition (FTE) обеспечивает надежную, контролируемую и управляемую передачу файлов любого размера между ИТ-системами без необходимости программирования. В предлагаемой статье описывается сценарий с тремя менеджерами очередей для настройки соединений по протоколу Secure Sockets Layer (SSL) с решением WebSphere MQ FTE.

Алекс Фенерс, разработчик программного обеспечения, IBM

Алекс Фенерс (Alex Fehners) – разработчик программного обеспечения, специализируется на создании приложений и на интеграции связующего ПО. Работает в лаборатории IBM Hursley Park (Великобритания). Адрес электронной почты: fehners@uk.ibm.com.



Лоренс Бонни, инженер по программному обеспечению, IBM

Лоренс Бонни (Laurence Bonney) – инженер по программному обеспечению. На протяжении восьми лет работает в лаборатории IBM Hursley Park (Великобритания). Является сотрудником группы по разработке продуктов WebSphere MQ и WebSphere MQ File Transfer Edition. Адрес электронной почты: bonneyl@uk.ibm.com.



29.12.2010

Введение

В данной статье демонстрируется, как сконфигурировать SSL-соединения (Secure Sockets Layer) с агентом продукта IBM® WebSphere® MQ File Transfer Edition (WMQFTE). Кроме того, в статье рассматриваются такие вопросы, как команды решения WMQFTE и подключаемый модуль WMQFTE для MQ Explorer (WMQFTE Plug-in for MQ Explorer), а также порядок соединения по протоколам TCP/IP с тремя раздельными менеджерами очередей продукта WebSphere MQ, а именно Agent queue manager, Command queue manager и Coordination queue manager. В статье демонстрируется, как создать тестовый сертификат и сконфигурировать менеджер очередей для организации защищенного SVRCONN-канала с решением MQ FTE. В статье не рассматриваются SSL-соединения между тремя менеджерами очередей.

Рассматриваемый в данной статье сценарий разработан для продуктов WMQFTE V7.0.2 и WebSphere MQ V7.0.1 в среде Microsoft® Windows®. Читатель должен обладать достаточным опытом работы с продуктом WebSphere MQ, чтобы в качестве отправной точки сконфигурировать сеть с тремя менеджерами очередей WMQFTE без применения протокола SSL. Хотя такая конфигурация и не описана в данной статье, вы легко сможете адаптировать указанный сценарий к конфигурации с единственным менеджером очередей. Для этого достаточно заменить каждую ссылку на менеджеры очередей Command, Coordination и Agent ссылкой на ваш единственный менеджер очередей, который будет сочетать функции менеджеров очередей всех трех типов в одном менеджере. При необходимости в статье приведены снимки экранов графических инструментов IBM Key Management и MQ Explorer, а также примеры командной строки.

Взаимодействие между менеджерами очередей и компонентами решения WMQFTE

Конфигурирование SSL для решения WMQFTE выполняется с помощью конфигурационных свойств в файлах свойств трех возможных типов, которые находятся в иерархии каталогов конфигурации WMQFTE: agent.properties, command.properties и coordination.properties. Конфигурация SSL для любого сценария в рамках WMQFTE зависит от обеспечивающих менеджеров очередей, с которыми вы устанавливаете соединение. Во многих случаях имеет место сценарий, в котором агенты должны подключаться по протоколу SSL только к своему менеджеру очередей (Agent), хотя в других, более сложных сценариях могут потребоваться SSL-соединения с другим менеджером очередей, например, с менеджером Coordination. Для конфигурирования топологии WMQFTE в соответствии с потребностями бизнеса необходимо понимание последовательности операций, которые данный менеджер очередей осуществляет с каждой из команд WMQFTE, с подключаемым модулем WMQFTE для MQ Explorer и с агентами.

Существует определенное заблуждение относительно подобного взаимодействия WMQFTE с менеджерами очередей. Например, некоторые пользователи полагают, что для выполнения команды fteListAgents требуется соединение с менеджером очередей Command. Эта команда предназначена для извлечения агентской информации внутри вашей сети WMQFTE, и, поскольку эта информация полностью хранится в менеджере очередей Coordination, эта команда нуждается в соединении только с менеджером очередей Coordination. Таким образом, если для подключения по SSL-соединению требуется эта команда, необходим файл SSL-конфигурации с именем «coordination.properties». С другой стороны, такие команды, как fteCreateTransfer, соединяются с менеджером очередей Command непосредственно. В таблице 1 показаны связи менеджеров очередей с некоторыми командами WMQFTE, подключаемым модулем WMQFTE для MQ Explorer и агентами. Для получения дополнительной информации по этой теме обратитесь к разделу «Which WebSphere MQ FTE commands connect to which queue manager» (Соединения между командами WebSphere MQ FTE и менеджерами очередей) в информационном центре по продукту WMQFTE.

Таблица 1.Связь объектов WMQFTE с менеджерами очередей различных типов
Объект WMQFTEМенеджер Agent queue managerМенеджер Command queue managerМенеджер Coordination queue manager
fteCreateTransferX
fteStartAgent (the Agent itself)X
fteStopAgentX
fteListAgentsX
Подключаемый модуль WebSphere MQ File Transfer Edition Plug-in for WebSphere MQ ExplorerXX

Всегда, когда имеется ссылка на менеджер очередей определенного типа, необходимо сконфигурировать SSL в соответствующем файле свойств WMQFTE, чтобы позволить объекту WMQFTE данного типа соединяться со своим менеджером очередей. Например, подключаемый модуль WMQFTE для MQ Explorer (из приведенной выше таблицы) нуждается в выполнении итераций как с менеджером очередей Coordination, так и с менеджером очередей Command, поскольку этот подключаемый модуль представляет команды менеджеру очередей Command (который создает передачи) и запрашивает информацию у менеджера очередей Coordination (который осуществляет передачи). Если оба упомянутых менеджера (менеджер очередей Coordination и менеджер очередей Command) должны быть сконфигурированы с поддержкой SSL-соединений, то конфигурационная информация WMQFTE SSL в файлах commands.properties и coordination.properties должна разрешать функционирование вышеуказанного подключаемого модуля.

Конечно, если поддержка SSL требуется для всей вашей топологии, то вы можете задействовать SSL на всех своих менеджерах очередей и поместить конфигурационную информацию SSL во все свои файлы свойств WMQFTE. Для упрощения статьи приведенный в ней пример сценария будет сконфигурирован именно таким образом.

Пример WMQFTE SSL

Как указывалось выше, в рассматриваемом примере демонстрируется, как сконфигурировать SSL для трех менеджеров очередей (AgentQmgr, CommandQmgr и CoordinationQmgr) и для агента WMQFTE с именем AGENT1 с помощью самоподписанных сертификатов.

  1. Создание на стороне клиента хранилища truststore, которое будет использоваться для агента, для команд WMQFTE и для подключаемого модуля для MQ Explorer.
  2. Создание хранилищ сертификатов для менеджеров очередей.
  3. Создание самоподписанных сертификатов для менеджеров очередей.
  4. Добавление сертификатов в хранилище truststore на стороне клиента.
  5. Конфигурирование файлов свойств WMQFTE.
  6. Конфигурирование менеджеров очередей.
  7. Создание и конфигурирование хранилища ключей (keystore) на стороне клиента для использования при аутентификации клиента (необязательно).
  8. Тестирование конфигурации.

Для конфигурирования базовых SSL-соединений необходимы все шаги, за исключением шага 7. Шаг 7 следует выполнять только в том случае, если необходимо сконфигурировать аутентификацию клиента. Если вы хотите уменьшить сложность и упростить отладку, то не следует применять аутентификацию клиента с самого начала. После того, как у вас будет сконфигурированное базовое SSL-соединение, работающее ожидаемым образом, вы сможете добавить аутентификацию клиента. Вы проверите, способны ли следующие четыре объекта WMQFTE соединяться с соответствующими менеджерами очередей:

  • Подключаемый модуль WMQFTE Plug-in for MQ Explorer
  • Тестовый агент AGENT1
  • WMQFTE-команды fteCreateTransfer и fteListAgents

Создание хранилища truststore на стороне клиента

Хранилище truststore содержит сертификат для менеджера очередей от подписывающего центра сертификации (Certificate Authority, CA), которому вы доверяете. Применительно к WMQFTE это означает, что при установлении соединения с менеджером очередей тот посылает свой сертификат в WMQFTE в рамках начального SSL-рукопожатия (handshake). Средства JSSE (Java Secure Socket Extension), которые обрабатывают все SSL-коммуникации, просматривают хранилище truststore для проверки только что полученного сертификата. Если они не в состоянии подтвердить указанный сертификат, соединение завершается. Для создания хранилища truststore воспользуйтесь инструментом IBM Key Management, который входит в состав продукта WebSphere MQ V7. Также можно использовать для этой цели программу keytool, входящую в состав Java-пакета установки WMQFTE.

  • В панели Start выберите Programs => IBM WebSphere MQ => IBM Key Management.
  • После запуска инструмента IBM Key Management нажмите на New и задайте следующие значения (см. рис. 1):
    • Key database type: JKS
    • File name: truststore.jks
    • Location: C:\WMQFTE_SSL\
  • Для продолжения нажмите OK.
  • Вам будет предложено ввести пароль по вашему выбору. Этот пароль требуется для открытия хранилища truststore только в том случае, если вы желаете добавить в него сертификаты. Библиотека JSSE не требует пароля, если она используется только в качестве хранилища truststore. Для данного примера введите пароль.
  • Для продолжения нажмите OK. Теперь у вас должно быть хранилище truststore, в которое вы сможете импортировать сертификаты от доверенных центров сертификации (CA).

Чтобы достичь аналогичного результата с помощью командной строки, введите команду runmqckm для Windows или gsk7cmd для Unix (см. листинг 1):

Листинг 1. Создание хранилища truststore
runmqckm -keydb -create -db C:\WMQFTE_SSL\truststore.jks -pw password 
-type jks
Рисунок 1. Создание хранилища truststore
Рисунок 1. Создание хранилища truststore

Создание хранилищ сертификатов для менеджеров очередей

В сценарии без аутентификации клиента хранилище сертификатов менеджера очередей действует таким же образом, как и любое хранилище keystore – оно содержит персональные сертификаты клиента. При конфигурировании дополнительной аутентификации клиента хранилище сертификатов менеджера очередей действует как хранилище truststore, а также хранилище keystore. Поскольку в описываемом сценарии вы используете самоподписанные сертификаты, то ваш персональный сертификат и сертификат от CA – это одно и то же, соответственно, хранилище сертификатов вашего менеджера очередей способно действовать и как keystore, и как truststore.

Файл key.kdb

Вы можете дать файлу-хранилищу сертификатов менеджера очередей любое имя, при условии, что этот файл будет иметь расширение .kdb. По умолчанию менеджер очередей использует для этого файла имя key.kdb, поэтому вам следует изменить свойство SSLKEYR менеджера очередей (с помощью runmqsc или MQ Explorer) в соответствии с выбранным вами значением.

В сценарии с тремя менеджерами очередей вы должны создать хранилище сертификатов менеджера очередей для каждого из используемых менеджеров. Как и на предыдущем шаге, для создания хранилища сертификатов вы можете использовать инструмент IBM Key Management:

  • Откройте инструмент IBM Key Management.
  • Нажмите New и задайте следующие значения (см. рис. 2).
    • Key database type: CMS
    • File name: key.kdb
    • Location: C:\Program Files\IBM\WebSphere MQ\Qmgrs\AgentQmgr\ssl\
  • Для продолжения нажмите OK.
  • Вам будет предложено ввести пароль по вашему выбору. Сделайте это, после чего выберите опцию Stash the password to a file.
  • Для продолжения нажмите OK. Теперь у вас должно иметься хранилище сертификатов для первого из ваших трех менеджеров очередей.
  • Повторите вышеописанные шаги для менеджеров CommandQmgr и CoordinationQmgr с целью создания хранилищ сертификатов для всех трех менеджеров.

Чтобы достигнуть аналогичного результата с помощью командной строки, вы можете выполнить с ее помощью команду runmqckm для Windows или gsk7cmd для Unix (см. листинг 2):

Листинг 2. Создание хранилища Keystore для менеджера очередей
runmqckm -keydb -create -db C:\Progra~1\IBM\Websph~1\qmgrs\AgentQmgr\ssl\key.kdb 
-pw password -type cms -expire 365 -stash
Рисунок 2. Создание хранилища сертификатов для менеджера очередей
Рисунок 2. Создание хранилища сертификатов для менеджера очередей

Создание самоподписанных сертификатов для менеджеров очередей

Значение метки ключа самоподписанного сертификата

Это значение должно быть представлено в форме <ibmwebspheremq<qmname lowercase>>. В рассматриваемом случае оно будет иметь одно из следующих значений:

  • ibmwebspheremqagentqmgr
  • ibmwebspheremqcommandqmgr
  • ibmwebspheremqcoordination

Создайте три самоподписанных сертификата, по одному для каждого менеджера очередей. Во избежание дополнительных осложнений создавайте каждый самоподписанный сертификат в хранилище сертификатов того менеджера очередей, к которому относится этот сертификат. Как и на предыдущих шагах, вы можете воспользоваться инструментом IBM Key Management:

  • Откройте инструмент IBM Key Management.
  • Нажмите Open, чтобы открыть хранилище сертификатов менеджера AgentQmgr.
  • Нажмите Create=>New Self-Signed Certificate и задайте следующие значения (см. рис. 3):
    • Key label: ibmwebspheremqagentqmgr
    • Common Name: <имя владельца или имя машины> (выберите подходящее значение)
  • Для продолжения нажмите OK.
  • Теперь у вас должен иметься персональный сертификат, присутствующий в списке как * ibmwebspheremqagentqmgr. Нажмите Extract certificate для извлечения самоподписанного сертификата в файл, чтобы позднее импортировать его в хранилище truststore на стороне клиента WMQFTE. Задайте следующие значения (см. рис. 4):
    • Data type: Binary DER data
    • Certificate file name: AgentQmgr.der
    • Location: C:\WMQFTE_SSL\
  • Для продолжения нажмите OK. Теперь у вас должен иметься первый из трех самоподписанных сертификатов.
  • Повторите вышеописанные шаги для менеджеров CommandQmgr и CoordinationQmgr с целью создания всех трех самоподписанных сертификатов.

Ускорение создания хранилища сертификатов и самоподписанных сертификатов

Если вы желаете сэкономить время, то нет никаких технических препятствий к тому, чтобы сначала создать одно хранилище сертификатов менеджера очередей, потом создать все сертификаты в этом единственном хранилище сертификатов, а затем скопировать файлы, содержащиеся в ssl-каталоге вашего менеджера очередей, в каждый из оставшихся менеджеров очередей. Таким образом для каждого менеджера вы будете использовать одно и то же хранилище. Оборотная сторона этого подхода состоит в том, что ваши самоподписанные сертификаты будут находиться в хранилище сертификатов вашего менеджера очередей, а все хранилища сертификатов будут использовать один и тот же пароль. Тем не менее для целей тестирования и демонстрации это вполне допустимо.

Чтобы достичь аналогичного результата с помощью командной строки, вы можете выполнить команду runmqckm для Windows или gsk7cmd для Unix (см. листинг 3):

Листинг 3. Создание и извлечение самоподписанного сертификата
runmqckm -cert -create -db C:\Progra~1\IBM\Websph~1\qmgrs\AgentQmgr\ssl\key.kdb 
-pw password -label ibmwebspheremqagentqmgr -dn CN=FTEUser -size 1024 
-x509version 3 -expire 365

runmqckm -cert -extract -db C:\Progra~1\IBM\Websph~1\qmgrs\AgentQmgr\ssl\key.kdb 
-pw password -label ibmwebspheremqagentqmgr -target C:\WMQFTE_SSL\AgentQmgr.der 
-format binary
Рисунок 3. Создание самоподписанного сертификата
Рисунок 3. Создание самоподписанного сертификата
Рисунок 4. Извлечение самоподписанного сертификата
Рисунок 4. Извлечение самоподписанного сертификата

Добавление сертификатов в хранилище truststore на стороне клиента

Теперь, после извлечения трех самоподписанных сертификатов (AgentQmgr.der, CommandQmgr.der и CoordinationQmgr.der), вам необходимо добавить их в хранилище truststore на стороне клиента WMQFTE. До тех пор, пока аутентификация клиента не будет введена, самоподписанный сертификат, который вы добавляете к хранилищу truststore, будет действовать как сертификат от CA. Как и на предыдущих шагах, вы можете воспользоваться инструментом IBM Key Management.

  • Откройте инструмент IBM Key Management.
  • Нажмите Open и откройте хранилище truststore клиента WMQFTE по адресу C:\WMQFTE_SSL\truststore.jks. После появления подсказки введите пароль, который вы вводили ранее.
  • Выберите ниспадающее меню под заголовком Key database content.
  • Выберите пункт Signer Certificates.
  • Нажмите Add. Вам будет предложено ввести местоположение сертификата, который вы желаете добавить. Этот сертификат будет или сертификатом менеджеров очередей (если вы используете самоподписанные сертификаты для тестирования), или сертификатом от центра CA, который выпустил сертификат для ваших менеджеров очередей. В данном примере используются самоподписанные сертификаты. Введите следующие данные (см. рис. 5):
    • Data type: Binary DER data
    • Certificate file name: AgentQmgr.der
    • Location: C:\WMQFTE_SSL\
  • Нажмите OK. Вам будет предложено ввести метку. Введите значение «ibmwebspheremqagentqmgr».
  • Нажмите OK, чтобы добавить сертификат.
  • Повторите вышеописанные шаги для менеджеров CommandQmgr и CoordinationQmgr, чтобы добавить подписанные сертификаты для всех трех менеджеров очередей.

Чтобы достичь аналогичного результата с помощью командной строки, вы можете выполнить команду runmqckm для Windows или gsk7cmd для Unix (см. листинг 4):

Листинг 4. Добавление самоподписанного сертификата в хранилище truststore клиента WMQFTE
runmqckm -cert -add -db C:\WMQFTE_SSL\truststore.jks -pw password -type jks 
-label ibmwebspheremqagentqmgr -file C:\WMQFTE_SSL\AgentQmgr.der -format binary 
-trust enable
Рисунок 5. Добавление самоподписанного сертификата в хранилище truststore клиента WMQFTE
Рисунок 5. Добавление самоподписанного сертификата в хранилище truststore клиента WMQFTE

Конфигурирование файлов свойств WMQFTE

Проверяя конфигурацию WMQFTE с помощью каких-либо из доступных объектов WMQFTE (см. таблицу 1), вы увидите, что менеджеры очередей всех трех типов будут непосредственно связаны с этими объектами. Поэтому вы должны добавить информацию о SSL-конфигурации во все три файла свойств:

Чтобы объект WMQFTE смог воспринять изменения в этих файлах свойств, его необходимо перезапустить. Однако на данный момент вы еще не закончили создание базовой конфигурации, поэтому подобный запуск скорее всего потерпит неудачу вследствие проблем с SSL-конфигурацией.

Свойства agentSslCipherSuite и agentSslCipherSpec, а также другие SSL- свойства агента

В данном примере используется свойство agentSslCipherSpec. Для согласованности с другими Java-клиентами MQ можно также использовать свойство agentSslCipherSuite. В общем случае специфицировать CipherSpec легче, поскольку вам достаточно обеспечить соответствие набору значений в своем канале MQ Server Connection. Если вы хотите специфицировать свойство CipherSuite, а не свойство CipherSuite, то обратитесь к таблице в разделе 4 статьи «SSL configuration of the WebSphere MQ Java/JMS client». Если оба типа свойств специфицированы в файле agent.properties, то свойство agentSslCipherSpec имеет приоритет над свойством agentSslCipherSuite. В версии WMQFTE V7.0.2 для агентов доступны и другие свойства SSL-конфигурации:

Для ознакомления с регулярно обновляемым списком SSL-свойств, доступных для WMQFTE, обратитесь в Информационный центр по продукту WMQFTE.

Конфигурирование файла agent.properties

Файл agent.properties, находящийся в корневом каталоге данных вашего агента, используется для конфигурирования всех аспектов поведения этого агента. Для использования SSL в описываемом сценарии добавьте или измените следующие значения:

Для файла свойств agent.properties в качестве комплекта SSL-шифров (SSL Cipher Suite) можно использовать значение RC4_MD5_EXPORT. Можно также использовать любое другое поддерживаемое значение при условии, что оно соответствует выбранному вами значению для соответствующего канала Server Connection вашего менеджера очередей Agent.

Конфигурирование файла coordination.properties

Файл coordination.properties находится в каталоге менеджера очередей Coordination под корневым каталогом данных. Для использования SSL в описываемом сценарии добавьте или измените следующие значения:

Для файла свойств coordination.properties в качестве комплекта SSL-шифров (SSL Cipher Suite) можно использовать значение DES_SHA_EXPORT. Кроме того, можно использовать любое другое поддерживаемое значение – при условии, что оно соответствует выбранному вами значению для соответствующего канала Server Connection вашего менеджера очередей Coordination.

Безопасность при использовании паролей в простом текстовом формате в файлах свойств

Пароли к хранилищам truststore и keystore хранятся в трех файлах свойств WMQFTE в простом текстовом формате. Вам необходимо ограничить круг лиц, которые будут способны прочитать эти файлы с помощью методов, доступных в вашей операционной системе. В файле выходного системного журнала менеджера Agent и внутри трассировочных файлов WMQFT эти пароли невидимы.

Конфигурирование файла command.properties

Файл command.properties находится в каталоге менеджера очередей Coordination под корневым каталогом данных. Для использования SSL в описываемом сценарии добавьте или измените следующие значения:

Для файла свойств Command в качестве комплекта SSL-шифров (SSL Cipher Suite) можно использовать значение TRIPLE_DES_SHA_US. Кроме того, можно использовать любое поддерживаемое значение – при условии, что оно соответствует выбранному вами значению для соответствующего канала Server Connection вашего менеджера очередей Command.

Конфигурирование менеджеров очередей

Конфигурация менеджера очередей в этом примере минимальна. Для каждого из трех менеджеров очередей в ней используется новый канал Server Connection с именем SYTEM.SSL.SVRCONN, который вы сможете создать с помощью инструмента MQ Explorer или инструмента runmqsc:

Рисунок 6. Задание SSL-соединения Server Connection
Рисунок 6. Задание SSL-соединения Server Connection
Листинг 5. Задание канала AgentQmgr SVRCONN в инструменте runmqsc
C:\WMQFTE_SSL>runmqsc AgentQmgr
5724-H72 (C) Copyright IBM Corp. 1994, 2009.  ALL RIGHTS RESERVED.
Starting MQSC for queue manager AgentQmgr.

DEFINE CHANNEL(SYSTEM.SSL.SVRCONN) CHLTYPE(SVRCONN) SSLCIPH(RC4_MD5_EXPORT) 
SSLCAUTH(OPTIONAL)
    2 : DEFINE CHANNEL(SYSTEM.SSL.SVRCONN) CHLTYPE(SVRCONN) SSLCIPH(RC4_MD5_EXPORT)
SSLCAUTH(OPTIONAL)
AMQ8014: WebSphere MQ channel created.
DISPLAY CHANNEL(SYSTEM.SSL.SVRCONN)
    3 : DISPLAY CHANNEL(SYSTEM.SSL.SVRCONN)
AMQ8414: Display Channel details.
CHANNEL(SYSTEM.SSL.SVRCONN)             CHLTYPE(SVRCONN)
ALTDATE(2009-11-19)                     ALTTIME(13.01.25)
COMPHDR(NONE)                           COMPMSG(NONE)
DESCR( )                                HBINT(300)
KAINT(AUTO)                             MAXINST(999999999)
MAXINSTC(999999999)                     MAXMSGL(4194304)
MCAUSER( )                              MONCHL(QMGR)
RCVDATA( )                              RCVEXIT( )
SCYDATA( )                              SCYEXIT( )
SENDDATA( )                             SENDEXIT( )
SHARECNV(10)                            SSLCAUTH(OPTIONAL)
SSLCIPH(RC4_MD5_EXPORT)                 SSLPEER( )
TRPTYPE(TCP)

Повторите вышеописанные шаги для CommandQmgr с использованием SSLCIPH(TRIPLE_DES_SHA_US) и для CoordinationQmgr с использованием SSLCIPH(DES_SHA_EXPORT). Теперь у вас должно иметься по одному каналу Server Connection с поддержкой SSL для каждого из ваших менеджеров очередей.

Создание и конфигурирование хранилища keystore на стороне клиента (необязательно)

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

Задание клиентского хранилища keystore

В данном сценарии используются самоподписанные сертификаты, что позволяет вам использовать существующее хранилище truststore также в качестве хранилища keystore для аутентификации клиента, поскольку сертификат действует как персональный сертификат и как сертификат от CA. Пароль, задание которого ранее не требовалось, теперь должен будет передаваться в JSSE для получения доступа к вашему персональному сертификату. Именно по этой причине он и был специфицирован ранее.

Задание хранилища keystore и пароля в файлах свойств

Изменения в файле agent.property:

Изменения в файле coordination.property:

Изменения в файле command.property

Изменение каналов менеджера очередей для задействования аутентификации клиента

Как и при первоначальном конфигурировании менеджера очередей, используйте инструмент MQ Explorer (рис. 7) или инструмент runmqsc (листинг 6) для изменения каналов Server Connection, которые вы создали раньше для всех трех менеджеров очередей.

Рисунок 7. Изменение SSL-соединения Server Connection для задействования аутентификации клиента
Рисунок 7. Изменение SSL-соединения Server Connection для задействования аутентификации клиента
Листинг 6. Изменение канала SVRCONN менеджера AgentQmgr в инструменте runmqsc
C:\WMQFTE_SSL>runmqsc AgentQmgr
5724-H72 (C) Copyright IBM Corp. 1994, 2009.  ALL RIGHTS RESERVED.
Starting MQSC for queue manager AgentQmgr.

ALTER CHANNEL(SYSTEM.SSL.SVRCONN) CHLTYPE(SVRCONN) SSLCAUTH(REQUIRED)
     1 : ALTER CHANNEL(SYSTEM.SSL.SVRCONN) CHLTYPE(SVRCONN) SSLCAUTH(REQUIRED)
AMQ8016: WebSphere MQ channel changed.
DISPLAY CHANNEL(SYSTEM.SSL.SVRCONN)
     2 : DISPLAY CHANNEL(SYSTEM.SSL.SVRCONN)
AMQ8414: Display Channel details.
   CHANNEL(SYSTEM.SSL.SVRCONN)             CHLTYPE(SVRCONN)
   ALTDATE(2009-11-19)                     ALTTIME(14.02.49)
   COMPHDR(NONE)                           COMPMSG(NONE)
   DESCR( )                                HBINT(300)
   KAINT(AUTO)                             MAXINST(999999999)
   MAXINSTC(999999999)                     MAXMSGL(4194304)
   MCAUSER( )                              MONCHL(QMGR)
   RCVDATA( )                              RCVEXIT( )
   SCYDATA( )                              SCYEXIT( )
   SENDDATA( )                             SENDEXIT( )
   SHARECNV(10)                            SSLCAUTH(REQUIRED)
   SSLCIPH(RC4_MD5_EXPORT)                 SSLPEER( )
   TRPTYPE(TCP)

Тестирование конфигурацииn

К этому моменту у вас должны иметься три менеджера очередей с SSL-каналом Server Connection у каждого; все эти менеджеры имеют собственные хранилища сертификатов, в которых содержатся самоподписанные сертификаты. В качестве опции вы, возможно, также задействовали аутентификацию клиента. Необходимо сконфигурировать WMQFTE таким образом, чтобы разрешить соединения с этими новыми каналами с поддержкой SSL. Теперь запуск MQ Explorer с подключаемым модулем WMQFTE, вашего агента AGENT1, сконфигурированного для поддержки SSL, или любой из команд WMQFTE установит соединение с соответствующими менеджерами очередей посредством SSL-канала (согласно таблице 1) под названием «Связь объектов WMQFTE с менеджерами очередей различных типов». Попытайтесь выполнить следующее:

  • fteStartAgent AGENT1 -- проверяет журнал output0.log на предмет успешной инициализации и соединения вашего агента.
  • fteListAgent -- Stdout должен продемонстрировать наличие агента AGENT1 в вашей сети WMQFTE.
  • fteFteCreateTransfer -sa AGENT1 -da AGENT1 -df C:\MyDestinationFile -w C:\MySourceFile -- должно быть выдано сообщение об успешном завершении передачи файлов; должен быть создан результирующий файл.
  • Подключение к менеджеру CoordinationQmgr через подключаемый модуль WMQFTE для MQ Explorer - узел WMQFTE в графическом интерфейсе пользователя MQ Explorer должен быть соединен с менеджером CoordinationQmgr.

Если все прошло успешно, то вы не должны увидеть каких-либо различий в поведении по сравнению с работой без SSL.

Лучший тест – это тест с отрицательными результатами

Вполне возможно, что тестирование ваших соединений покажет, что вы соединяетесь с вашим менеджером по каналу без SSL и не создали ни одной конфигурации на стороне WMQFTE. Простой способ проверить наличие SSL-конфигурации состоит в намеренном использовании несоответствующих комплектов шифров у вашего решения WMQFTE и в канале менеджера очередей. Запуск вашего агента при таком несовпадении конфигураций должен привести к невозможности установления соединения с менеджером очередей с кодом ошибки MQRC 2397 - MQRC_JSSE_ERROR. Теперь приведите комплекты шифров в соответствие друг с другом, после чего агент должен успешно запуститься. Ниже показаны примеры выходной информации при неудачном соединении для менеджеров очередей каждого из трех типов.

Листинг 7. Выходная информация при неудачном соединении с менеджером (подключение к менеджеру AgentQmgr)
BFGAG0115I: Relative path transfer root directory: C:\Documents and Settings\Laurence
BFGAG0058I: The agent has successfully initialized.
BFGAG0052E: The agent received MQI reason code 2397 when establishing a client transport
    mode connection to the queue manager 'AgentQmgr' on host 'localhost', port '5050' and
    using channel 'SYSTEM.SSL.SVRCONN'.  The agent cannot continue and will end.
BFGAG0061E: The agent ended abnormally
Листинг 8. Выходная информация при неудачном соединении с менеджером (подключение к менеджеру CommandQmgr)
C:\Program Files\IBM\WMQFTE\bin>fteListAgents 
5655-U80, 5724-R10 Copyright IBM Corp.  2008, 2009.  ALL RIGHTS RESERVED
BFGCL0002E: A messaging problem prevented the command from completing successfully.
The WebSphere MQ completion code was 2, and the reason code was 2397.  
A connection could not be established to queue manager CoordinationQmgr, 
on host 'localhost' using port 5052 and channel SYSTEM.SSL.SVRCONN.
Листинг 9. Выходная информация при неудачном соединении с менеджером (подключение к менеджеру CoordinationQmgr)
C:\Program Files\IBM\WMQFTE\bin>fteCreateTransfer -sa AGENT1 -da AGENT1 -df 
C:\MyDestinationFile -w C:\MySourceFile 
5655-U80, 5724-R10 Copyright IBM Corp. 2008, 2009.  ALL RIGHTS RESERVED 
com.ibm.wmqfte.api.TransportException: BFGCL0002E: A messaging problem prevented
the command from completing successfully. The WebSphere MQ completion code was 2, 
and the reason code was 2397.  A connection could not be established to queue manager 
CommandQmgr, on host 'localhost' using port 5051 and channel SYSTEM.SSL.SVRCONN.

Заключение

В статье показано, как сконфигурировать три менеджера очередей WMQFTE в сценарии с SSL, и рассмотрены такие вопросы, как агент и команды решения WMQFTE, а также подключаемый модуль WMQFTE для MQ Explorer. Кроме того, описана базовая конфигурация решения MQ для SSL-подключения к объектам WMQFTE, а также возможная аутентификация клиента.

Устранение неполадок

Исправление ошибок SSL может оказаться непростой задачей. При возникновении неожиданных сбоев аутентификации в первую очередь проверьте следующие два места:

  • Файлы Agents Output0.log -- ищите любую информацию относительно действий, которые должны были произойти.
  • Журналы ошибок менеджеров очередей -- ищите подробности относительно неудавшихся соединений.

Как правило, первопричиной неполадок являются ошибки конфигурации, поэтому тщательная проверка соответствия конфигураций клиента и сервера способна избавить вас от множества проблем. Сложные сценарии следует осуществлять поэтапно, сопровождая каждый этап надлежащей проверкой. «Одномоментное» создание сложного сценария (со списками аннулированных сертификатов, с аутентификацией на стороне клиента и т.д.) скорее всего породит многочисленные конфигурационные проблемы, изоляция и устранение которых будет сопровождаться значительными трудностями.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere
ArticleID=605384
ArticleTitle=Конфигурирование подключения по протоколу Secure Sockets Layer в решении WebSphere MQ File Transfer Edition
publish-date=12292010