Команды для обновления хранилища ключей Java с обновлением Symantec с использованием нового CSR (не исходного CSR)

Два года назад я получил сертификат VeriSign/Symantec SSL. При инициировании этого запроса мы создали CSR на случайном сервере, который не связан с общим именем сертификата. Чтобы создать Java Keystore, я сделал следующие два шага.

openssl pkcs12 -export -in common_name.cer -inkey common_name.key -out renewal.p12 -name common_name_alias -CAfile NewVerisignIM.cer -caname root

keytool -importkeystore -deststorepass XXX! -destkeypass XXX!
-destkeystore renewal.keystore -srckeystore renewal.p12 -srcstoretype PKCS12 -srcstorepass XXX! -alias common_name_alias

Срок действия нашего сертификата истекает. При использовании исходной записи на веб-сайте Symantec и создании нового CSR мы получили файл подписанного сертификата (с тем же именем файла, что и common_name.cer выше), закрытый ключ (то же имя файла, что и common_name.key выше). После подписания нового CSR мы НЕ получили файл "NewVerisignIM.cer", который, по-видимому, является корневым и промежуточным ЦС, объединенными в один файл (я считаю, что это цепочка ЦС). Так что я не знаю, как воссоздать хранилище ключей Java без этого файла.

Я пытался использовать старый "NewVerisignIM.cer" с новыми файлами после подписания, но это не сработало. Это все, что я пробовал до сих пор. Я получил исключение Java

Сбой построения пути PKIX: sun.security.provider.certpath.SunCertPathBuilderException: невозможно найти действительный путь сертификации для запрошенной цели

Этот сайт содержит инструкции по использованию оригинального CSR и JKS.

https://knowledge.symantec.com/kb/index?page=content&id=SO11942&pmv=print&actp=PRINT&viewlocale=en_US

Но этот вопрос / ответ рекомендует использовать новый CSR.

Обновить сертификат с помощью Java Keytool - повторно использовать старый CSR?

Какие команды я могу использовать, если мы используем новый CSR?

1 ответ

Решение

У меня были правильные команды. Новый закрытый ключ необходим в первой команде (от X509 до PKCS12). Новый подписанный сертификат необходим в первой команде. И исходный файл цепочки CA, когда был создан исходный сертификат, необходим в первой команде. Обновление не содержало этот файл в качестве вывода. В 2015 году Verisign, вероятно, еще не был приобретен Symantec, поэтому файл назывался "NewVerisignIM.cer". Вторая команда выше преобразует из PKCS12 в формат JKS (Java Keystore).

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

Команды запускаются на сервере (создается новое хранилище ключей):

openssl pkcs12 -export -in common_name.cer -inkey common_name.key -out renewal.p12 -name common_name_alias -CAfile NewVerisignIM.cer -caname root

keytool -importkeystore -deststorepass XXX! -destkeypass XXX!
-destkeystore renewal.keystore -srckeystore renewal.p12 -srcstoretype PKCS12 -srcstorepass ppp1 -alias common_name_alias

keytool -export -alias https-renewal -file https-renewal.pem -keystore renewal.keystore

Команды выполняются на клиенте (хранилище ключей остается прежним):

keytool –delete –alias https-renewal –keystore original.keystore –storepass ppp2

keytool -import -v -alias https-renewal -file https-renewal.pem -keystore original.keystore -storepass ppp2

(где "https-renewal.pem" - файл, экспортированный из 3-й команды в этом ответе)

Другие вопросы по тегам