Личный сертификат iKeyman исчез

Вы правы в том, что у KDB нет личного сертификата и выдающегося CSR. Однако, если сертификат с меткой ibmwebspheremqusapp1u является тем, который должен быть личным сертификатом, теперь он загружается как доверенный сертификат. Невозможно восстановить закрытый ключ из KDB, как описано, и если нет файла резервной копии, этот сертификат не подлежит восстановлению. Лучшее, на что вы можете надеяться, это то, что ЦС позволяет клиентам повторно использовать сертификат.

Невозможно достичь этого состояния без выдачи runmqakm -cert -add. Ожидаемой командой была бы runmqakm -cert -receive, которая объединила бы ответ от ЦС с исходным ожидающим CSR и создала бы полный персональный сертификат. Либо это было сделано, либо это не та KDB, в которой был создан этот CSR, потому что, как вы указываете, нет незавершенных CSR.

Предполагая, что это не вызвано ошибкой GSKit и что это та же KDB, в которой был создан CSR, в какой-то момент после успешного получения CSR личный сертификат был удален, а ответ от CA повторно добавлен с использованием runmqakm -cert -add. Альтернативой является то, что CSR был явно удален (о чем, я полагаю, вы бы помнили, если бы это было так), или же у GSKit есть неприятная и опасная ошибка, которую вы пока единственный человек обнаружили.

С этой стороны экрана сложно однозначно определить ошибку GSKit или ошибку пользователя, однако с вашей стороны возможно: а) предотвратить повторение подобного; и б) возможно, сделать это окончательное определение. «Как мне это сделать?» — спросите вы?

Всегда делайте резервную копию KDB или JKS, прежде чем выполнять против них команды, если в них есть закрытый ключ, CSR или личный сертификат. Вы всегда можете восстановить доверенные сертификаты, но закрытый ключ или все, что его содержит, является единственным в своем роде и незаменимым. Не рискуйте потерять его, оперируя единственной существующей копией.

Например, после отправки CSR и получения ответа от ЦС скопируйте файлы key.* в key.[timestamp].* и пометьте файлы резервных копий как доступные только для чтения перед получением CSR обратно. Если receive завершится успешно, все готово. Если нет, вы можете скопировать резервные копии поверх поврежденного kdb или в новый набор файлов kdb (никогда не работайте с резервными копиями!) и попытаться воссоздать проблему, чтобы определить, является ли это ошибкой или ошибкой пользователя.

Резервная KDB с ожидающим CSR всегда вернет вас к состоянию, в котором вы находились сразу после создания CSR, чтобы вы могли повторять свои шаги столько раз, сколько необходимо. Если вы можете надежно воссоздать ошибку и считаете, что это ошибка GSKit, откройте PMR в IBM. Это маловероятный сценарий, но я знаю, что это происходит, потому что однажды я обнаружил ошибку GSKit, которая уничтожает все хранилище ключей. Отсюда моя рабская приверженность стратегии резервного копирования перед изменением. Как и вы, я тоже выучил это на собственном горьком опыте.