Для получения ответов на этот вопрос потребуется немного фона.
Когда вы изначально создали CSR, то, что вы на самом деле получили, это пара открытого и закрытого ключей и запрос на подпись сертификата или «CSR». CSR содержит открытый ключ и запрашиваемые атрибуты, такие как Distinguished Name. CSR подписывается с вашим личным ключом, чтобы любой получатель мог использовать встроенный открытый ключ для проверки того, что CSR и запрошенные атрибуты не были подделаны.
Что менее известно, так это то, что ЦС не обязан применять все атрибуты, предоставленные в КСО. Например, если приобретенный сертификат является сертификатом с подтверждением домена, а CSR содержит значения для поля OU, CA просто удалит их, оставив только поля DN и SAN, а также их собственную информацию. Таким образом, сертификат, который вы получите, может иметь разные поля, чем исходный CSR.
Когда вы воссоздаете CSR из действующего сертификата, тот же процесс происходит снова, за исключением того, что новая CSR отражает любые изменения, сделанные CA изначально. Закрытие проверки подлинности CSR и недавно созданного обычно показывают различия в SAN или что в DN добавлен контакт электронной почты. Однако с точки зрения CA эти различия являются косметическими.
Имея это в виду, давайте рассмотрим вопросы снова.
Когда у меня есть два сертификата как RenewalCOMODO и oldCOMODO, как менеджер очередей знает, что правильно?
Предполагая, что вы говорите об артефактах, предоставленных ЦС после ответа на оригинал и обновление CSR, QMgr не знает, что именно.Вы можете запустить команду receive и, предположив, что оба они были подписаны одним и тем же ЦС и используют одну и ту же цепочку подписчиков, либо будут работать.
Администратор несет ответственность за проверку правильности установки сертификата.
Если он выбирает, срок действия которого не истек, не будет ли он иметь истекший в базе данных?
Нет. Каждая успешная команда receive хранит личные части личного сертификата и заменяет общедоступные части. Метка связана с частной частью, и это проверяется на уникальность, поэтому вы не можете (или, по крайней мере, , если нет, если нет ошибок) иметь две копии в одном KDB.
Если нам нужно удалить старый, добавив обновленный, как он будет отличаться от замены сертификатов?
Просто убедитесь, что вы получили правильный сертификат. Всегда выполняйте команду runmqakm -cert -details или проверяйте сертификат, используя графический интерфейс пользователя.
Дополнительные рекомендации:
- Всегда делают копию КДБ перед началом работы на нем.
- Сохраните копии своих CSR и сертификатов в каталоге KDB.
- Мне нравится использовать временные метки в именах файлов, поэтому очевидно, что такое история. Мои имена файлов начинаются с YYYYMMDD, например
20150908_QMName_CSR.arm и 20150908_QMName_CSR_signed.arm.
- Убедитесь, что права доступа к файлам сертификатов, KDB и каталогам, содержащим их, запрещены любым другим пользователям, кроме учетной записи службы MQM. Если это невозможно, разрешите доступ к группе, но убедитесь, что члены группы mqm как можно меньше. Любой, кто может прочитать сертификаты, может их использовать. Нет необходимости знать пароль для KDB для использования сертификатов, которые он содержит.
- При выполнении техобслуживания мне нравится делать новую копию KDB (с временным именем файла, как описано ранее), и когда я уверен, что он готов, я изменяю атрибут QMgr
SSLKEYR, чтобы указать на него. Затем я изменяю старый файл только для чтения и выдаю RESET SECURITY TYPE(SSL) на QMgr.
- Всегда помните о выпуске
RESET SECURITY TYPE(SSL) на QMgr. Это довольно разрушительная команда, поэтому старайтесь не выпускать ее, когда QMgr занят. Это потребует, чтобы все каналы были отключены, и много попыток повторного подключения не позволят ему быстро завершить работу.