У меня есть приложение (Cognos), которое доставляет веб-страницы с помощью двух механизмов: через IIS и через приложение Java. Нам нужно включить SSL для обоих. IIS был готов. Сейчас мы работаем над Java-апплетом.
Сертификат IIS был сгенерирован путем создания запроса сертификата в IIS и отправки его в ЦС. Они вернули сертификат, который мы установили в IIS, и все в порядке - мы можем получить доступ к этим страницам в браузере, используя HTTPS.
Я попытался импортировать этот же сертификат в хранилище сертификатов Java-приложений. Однако я получил ошибки, связанные с приложением.
Это было сделано с помощью специального инструмента командной строки приложения.
Но в основном похоже, что он пытается заменить существующий неподписанный сертификат под псевдонимом шифрование с подписанным сертификатом.
Вот страница, на которой показан процесс с использованием предоставленного инструмента с графическим интерфейсом
http://www-01.ibm.com/support/docview.wss?uid=swg22004239
Моя проблема в том, что сертификат уже был возвращен из центра сертификации, и я не генерировал запрос в этом инструменте.
У меня есть действующий сертификат, но я не могу следовать этим инструкциям, поскольку они предполагают, что запрос был сгенерирован из этого хранилища ключей.
Пройдя процесс, кажется, что нам нужно сгенерировать CSR из хранилища сертификатов Cognos, отправить его в CA и получить другой сертификат для того же хозяин, но другой исходный CSR.
Это будет означать, что у нас есть два сертификата для одного и того же хоста, что для меня не имеет смысла.
Прежде всего:
РЕДАКТИРОВАТЬ:
Продолжая исследовать это, я понимаю, что при генерации запроса закрытый ключ сохраняется в хранилище ключей. Поэтому я думаю, что проблема не в том, что у меня два хранилища ключей, проблема в том, что я не знаю, как повторно использовать закрытый ключ из исходного хранилища ключей во втором хранилище ключей.
Вам нужно будет экспортировать ключ и сертификат из IIS. Вы должны иметь возможность экспортировать это в файл PKCS7. Использовать keytool чтобы импортировать это в ваше хранилище ключей Java. (При желании также можно использовать файл PKCS7.)
Если IIS доставляет апплет, вам не нужен сертификат сервера для апплета. Если вы используете другой сервер для доставки апплета, вам нужно будет импортировать ключ на этот сервер.
Я полагаю, ваша проблема связана с подписанием апплета. Ваш ключ не может быть помечен как пригодный для подписи кода. Используйте такой инструмент, как keytool или браузер для отображения флажков на сертификате. Возможно иметь сертификат, который будет полезен как для сервера, так и для подписи кода.
EDIT: похоже, у вас есть сертификат, который подходит как для кода подписи. (Вы должны подписать свой апплет.) И он также подходит для шифрования (HTTTPS). Если вы хотите использовать его для HTTPS, у него должно быть альтернативное имя субъекта для каждого домена, с которым вы хотите его использовать. Это позволит подтвердить, что сертификат предназначен для домена.
Обычно вы не используете апплет в качестве сервера. Он может открывать соединения с сервером, с которого он был загружен, для поиска дополнительных классов. Это также может быть открытие дополнительных подключений к другим серверам. Современные браузеры захотят, чтобы вы указали доступ, который необходим апплету, чтобы пользователь мог проверить, предоставлять ли его или нет.
ЦС может одобрить запрос на множественный доступ клиентов или один сертификат для каждого домена на один хозяин (демонстрирует, как назначить каждый с помощью виртуальных хостов)
Чтобы ответить на второй вопрос, см. этот ответ на другой аналогичный вопрос, как экспортировать и импортировать сертификаты.
keytool -importkeystore -srckeystore mypfxfile.pfx -srcstoretype pkcs12
-destkeystore clientcert.jks -deststoretype JKS
Это должно импортировать ваш pfx в хранилище ключей. Это было то, что я использовал в последний раз, когда мне нужно было импортировать pfx