Можно ли повторно использовать сертификат WebSphere MQ TLS/SSL?

Question

Скажем, я использовал диспетчер очереди QMGR1 в host1 для создания CSR и получения сертификата с подтверждением CA, помеченного как ibmwebspheremqqmgr1. Могу ли я использовать нагрузку того же сертификата (и его корневой и промежуточной цепей) в другом хосте-хосте2 для управляемой очереди с таким же (то есть QMGR1)? Другими словами, certreq должен присутствовать, когда мы «получаем» сертификат с использованием rumqakm или нет? Можем ли мы просто «добавить» сертификат (например, мы делаем цепочки)? Если вопрос непонятен, пожалуйста, спросите, я могу предоставить более подробную информацию. В моем случае host2 - это производство. host1 - это среда QA, где мы проверяем подключение. Благодарю.

Обновить вопрос от комментариев 26DEC16
Конкретного к MQ, я считаю, что я должен был бы загрузить CSR первого на host2, а затем снова получить С, не так ли? Интересно, как я могу загрузить CSR без его создания. Я вижу вариант воссоздать его в runmqakm, никогда не использовал это раньше и не уверен, что это сработает.

Answer 1

TL; DR: Да.

Когда вы создаете CSR с использованием IBM GSKit (например, runmqakm), результатом является сертификат без знака и сам файл CSR. CSR криптографически привязан к неподписанному сертификату, который остается в файле .rdb хранилища ключей. Подписанный CSR не может быть получен в любое хранилище ключей в этот момент.

Когда вы получаете подписанный CSR, он комбинируется с незавершенным беззнаковым сертификатом и перемещается в файл .kbd хранилища ключей. На данный момент это действительный персональный сертификат с указанным именем метки (ibmwebspheremqqmgr1) и указанным вами DN.

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

• Скопируйте набор файлов, составляющих хранилище ключей.
• Экспортируйте персональный сертификат в файл, а затем импортируйте его в другое хранилище QMgr.

Если вы скопировали все хранилище ключей, а другое QMgr также названо QMGR1, вы можете использовать их немедленно. Если другое QMgr имеет другое имя, вам придется переименовать сертификат на что-то другое, кроме ibmwebspheremqqmgr1, или в современном QMgr установите атрибут QMgr CERTLABL на ibmwebspheremqqmgr1. Как правило, вы хотите, чтобы метка cert отражала имя QMgr, используя ее, поэтому не рекомендуется использовать QMgr с именем QMGR2 с CERTLABLibmwebspheremqqmgr1.

Если вы импортируете сертификат, вы можете установить метку во время команды импорта.

Имейте в виду, что ярлык и отличительное имя - это две совершенно разные и несвязанные вещи. Различающееся имя - это значение, которое CA проверяет и подписывает и криптографически связывает его ключи в сертификате. Это то, что партнер удаленного соединения решает, доверять или нет.

Метка: локальный QMgr или клиент находит собственный сертификат. Представьте, что вы создали два личных сертификата, QMgr должен знать, какой из них отправлять. Он находит правильный, сопоставляя метку сертификата с ожидаемым значением ibmwebspheremq[qmgr name in lower case] или с атрибутом QMgr CERTLABL, если он не пуст.

Именно поэтому ярлык сертификата можно легко изменить с помощью команды GSKit, но Distinguished Name является неизменным.

Учитывая это, обратите внимание, что внешние и многие внутренние ЦС будут ожидать, что сертификат Common Name сертификата будет содержать полное имя хоста, в котором будет использоваться сертификат. Клиенты HTTPS проверяют, соответствует ли сертификат CN имени хоста при их подключении. Для подключения MQ это не так. Вы можете поместить что-нибудь в CN, что ваш CA подпишет и будет использовать его в QMgr любого произвольного имени. Таким образом, ваш сертификат может содержать CN=QMGR1 и что QMgr может жить на mqhost.yourcompany.com, а MQ очень нравится. Тем не менее, клиенты , использующие новый API MQ REST, не будут! Это важное различие для людей, надеющихся использовать новый API MQ REST.

И, наконец, обратите внимание, что лучше всего создавать сертификаты, в которых они будут использоваться, защищать их, используя разрешения файловой системы, хранить их в локальном хранилище и никогда не копировать и не перемещать их из этого места. Криптору Public/Private key было изобретено решение очень сложной проблемы безопасного обмена секретными ключами. Если персональные сертификаты копируются вокруг, это наносит ущерб цели их использования в первую очередь.

Различные коммерческие пакеты PKI (то есть IBM Tivoli Key Lifecycle Manager, Venafi и т. Д.) Решают эту проблему с помощью FIPS-сертифицированных алгоритмов, которые не хранят на диске ключи или крипто-примитивы, надежно протрите пространство памяти, прежде чем выпускать его , и вообще принимать мучительную заботу, чтобы не оставить ключи незащищенными в пути, диске или памяти. Если вы должны скопировать личные сертификаты, используйте настоящий пакет PKI, предназначенный для этой цели, если у него есть один. В противном случае экспортируйте их в .p12 с очень длинным и случайным паролем и избегайте использования электронной почты, FTP или других незащищенных средств копирования файла.