Ошибка, которую вы видите, состоит в том, что ваше хранилище ключей не имеет корневого и / или промежуточного сертификатов подписывающего CA. Когда вы получаете подписанный сертификат от центра сертификации, он должен быть проверен перед добавлением его в хранилище ключей. Почти любой мог бы перехватить ваш запрос на подпись и подписать сертификат. Этап проверки при получении гарантирует, что он был подписан центром сертификации, которому вы действительно доверяете, а не каким-то анонимным посредником.
Способ проверки сертификата заключается в проверке подписи СА против открытого ключа СА, который находится в вашей KDB. Для этого сертификат CA должен быть уже в KDB, когда вы пытаетесь получить подписанный сертификат. Если ЦС использует промежуточный сертификат подписавшего (и по ряду причин любой коммерческий ЦС будет использовать промежуточные сертификаты), необходимо также импортировать промежуточный сертификат и корневой сертификат. Это формирует цепочку сертификатов или путь сертификата от корневого сертификата ЦС через любые промежуточные сертификаты к подписанному сертификату. Каждая вещь в цепочке аутентифицируется вещью над ней, пока вы не доберетесь до корня. Ваш KDB должен иметь всю цепочку, и, поскольку каждый сертификат проверяется тем, который находится над ним, вы должны импортировать их, начиная с корня и работая вниз.
Обычно ваш ЦС размещает свои сертификаты подписавшего на своем веб-сайте, где вы получаете их с использованием SSL. Получите их и импортируйте, и вы сможете получить подписанный сертификат.
Так получилось, что The Sphere Online Journal только что опубликовал статью, в которой вы познакомитесь с этим процессом, используя Verisign в качестве примера и снимки экрана с импортом корневых и промежуточных сертификатов подписавшего. Эта статья о обновлении сертификатов WebSphere MQ , но первая часть статьи создает файл kdb и запрос на подпись, затем импортирует сертификаты CA и подписанный сертификат.
Давайте также доставим вас в правильный инфоцентр. Ознакомьтесь с разделом Инфоцентра WMQ v7.0 по Использование подписанных сертификатов CA . Тот, на который вы смотрели, предназначен для Message Broker, и, откровенно говоря, статья, на которую вы ссылались, немного беспорядочная. Я посмотрю, как это исправить. Для начала, этот бит о создании сертификата в одном kdb, получении его подписи, затем его экспорте, удалении и импорте в KDB QMgr - это просто мусор. Просто сгенерируйте CSR в собственном файле KDB QMgr и получите подписанный сертификат непосредственно к нему. Это намного проще и это процесс, проиллюстрированный в статье, упомянутой выше.
Наконец, если вы зайдете на t-rob.net и загрузите Лабораторию безопасности WMQ с IMPACT 2011, вы найдете там руководство по лаборатории и некоторые сценарии. В них используются самозаверяющие сертификаты, но сценарии можно легко преобразовать в сертификаты, подписанные CA, а затем адаптировать их для использования в сети WMQ.
UPDATE:
Отвечая на дополнительные вопросы в комментариях:
На самом деле я планирую использовать самозаверяющий сертификат, поэтому мне кажется, что мне нужно только извлечь его и добавить в доверенное хранилище клиента?
Да, это правильно. Но вот проблема на странице Инфоцентра WMB, которая изначально была связана с тем, что она просит вас создать сертификат с меткой qmgrname вместо ibmwebspheremqqmgrname. QMgr находит свой сертификат на основе метки, поэтому он должен соответствовать указанному формату. Поэтому, когда вы создаете свой самоподписанный сертификат, убедитесь, что метка является литералом ibmwebspheremq с именем QMgr, сложенным в нижний регистр. Если вы сделали сертификат с неправильной меткой, вы всегда можете экспортировать его в файл P12 и затем импортировать его в новый KDB с правильной меткой.
Я использовал мастер WMQ SSL, упомянутый в WMQ Security Lab, для создания правильной конфигурации.Конфигурация прошла гладко, но когда я запускаю пример JMS, включенный в мастер SSL, я получаю ошибку MQJE001: Completion Code '2', Reason '2397', в журналах SSL отображается следующая ошибка main, received EOFException: error main, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake main, SEND TLSv1 ALERT: fatal, description = handshake_failure
Существует несколько причин, по которымэто может произойти.Вместо того, чтобы пройти через все из них, я предложу некоторые методы диагностики.Когда я настраиваю каналы SSL, я всегда использую следующую процедуру:
- Получите канал, работающий без SSL.Это доказывает, что основной канал связи работает (прослушиватель работает, порты соответствуют, определения объектов канала совпадают и т. Д.).
- Если QMgr впервые использует SSL или если kdb изменился, обязательно введите команду
REFRESH SECURITY TYPE(SSL). - Включите SSL, указав один и тот же набор шифров на QMgr и клиенте, но убедитесь, что канал SVRCONN QMgr установлен на
SSLCAUTH(OPTINAL) SSLPEER().Это подтверждает, что клиент принимает сертификат QMgr .Только когда это работает, переходите к следующему шагу. - Теперь измените SVRCONN QMgr на
SSLCAUTH(REQUIRED) SSLPEER().Это заставляет QMgr запрашивать сертификат клиента. - При использовании
SSLPEER установить его на нужное значение.
Этот процесс изолирует возможные проблемы, чтобы в любой момент вы зналигде искать.Если процесс завершается с ошибкой на шаге 3, то либо есть проблема с конфигурацией SSL приложения, либо он не может проверить сертификат QMgr.Если на шаге 4 процесс завершается неудачно, мы знаем, что конфигурация SSL приложения является надежной, и что ему нравится сертификат QMgr, что QMgr не нравится сертификат приложения.Если мы перейдем к шагу № 5, то это просто вопрос правильного значения SSLPEER.
Поскольку у вас произошел сбой при рукопожатии, который, по-видимому, связан с закрытием TCP-соединения QMgr, я предполагаю, чтоу вас есть SSLCAUTH(REQUIRED) (кстати, по умолчанию), и что либо QMgr не имеет сертификата приложения, либо вы пытались использовать анонимное соединение, когда клиенту не требуется личный сертификат.В этом случае настройка SSLCAUTH(OPTIONAL) позволит вам преодолеть точку отказа, хотя, возможно, и перейти к совершенно новой точке отказа.