С точки зрения Java, вы должны сначала попытаться понять разницу между хранилищем ключей и хранилищем доверенных сертификатов (оба хранилища ключей используются для различных целей).
В JSSE нет хранилища ключей по умолчанию, но некоторые приложения по умолчанию используют $HOME/.keystore: это то, что содержит ваш сертификат, для которого у вас есть закрытый ключ.
Напротив, склад доверенных сертификатов определяет, каким удаленным сертификатам вы готовы доверять. Он содержит ряд сертификатов CA, к которым может быть установлен путь сертификации при обнаружении нового сертификата. Если такой путь существует (и если сертификат не отозван, если он активирован), этот (априори) неизвестный сертификат считается доверенным.
Похоже, процедура, которую вы использовали, состояла в создании собственного центра сертификации, поэтому вы получите файл сертификата CA и его закрытый ключ (который, вероятно, будет этим файлом CAkey.pem). Это должно использоваться только для выдачи новых сертификатов с этим CA.
если мы используем авторизованный CA, например verisign, они обеспечивают 128-битное шифрование
который, вероятно, хранилище ключей по умолчанию расширено командой java keytool
сертификатов нет).
Это не сертификат, который используется для выбора размера ключа шифрования, это набор шифров. ( Эра сертификатов SGC закончилась .)
Во время рукопожатия SSL / TLS сертификат сервера используется для проверки подлинности сервера (чтобы гарантировать, что клиент обменивается данными с сервером, с которым он хочет общаться) и для согласования набора общих симметричных ключей (в зависимости от шифра). Suite): это те, которые используются для шифрования.
Если вы хотите сгенерировать сертификат с keytool для определенного размера ключа, используйте -keysize 2048 (например). Обратите внимание, что это размер ключа в сертификате, а не размер симметричных ключей, используемых для самого шифрования.
Более или менее ту же команду с keytool можно использовать для генерации CSR для отправки в коммерческий ЦС. Независимо от того, используете ли вы коммерческий CA или свой собственный, не имеет значения w.r.t. сила шифрования. Разница в том, что никто не распознает ваши собственные сертификаты по умолчанию, поэтому вам придется явно импортировать их в ваших клиентах. Сертификаты в основном полезны для проверки личности удаленного объекта, с которым вы общаетесь.
(Вас также могут заинтересовать дискуссии по этому вопросу .)
EDIT:
Вы смешали две совершенно разные процедуры.
1. Создание собственного CA.
Что вы сделали с OpenSSL, так это сгенерировали свой собственный центр сертификации (CA). Следовательно, вы получаете CAcert.pem и CAkey.pem, которые являются сертификатом CA и его закрытым ключом (используется для выдачи новых сертификатов с этим CA). Если вы пойдете по этому пути, все, что вам нужно сделать, это импортировать CAcert.pem в качестве доверенного сертификата ЦС на ваших клиентах, и сертификаты, которые вы выдаете с ним, будут доверенными. Вы также можете быть заинтересованы в OpenSSL CA.pl , который представляет собой сценарий, который охватывает многие из процедур, которые вы, возможно, сделали больше вручную.
OpenSSL не может работать с файлами JKS, и эта процедура не очень полезна без нескольких дополнительных шагов. Отсюда вы можете:
- Создайте ключ + сертификат для вашего сервера, используя OpenSSL (CA.pl должен помочь). С точки зрения Java проще экспортировать его в формате PKCS # 12 (файл
.p12): тогда вы сможете использовать этот файл непосредственно из Java в качестве хранилища ключей типа PKCS12 (keystoreType="PKCS12" в ваша конфигурация).
- Создайте CSR с помощью
keytool через -certreq, выдайте сертификат с помощью OpenSSL (опять же, CA.pl должен помочь), повторно импортируйте этот сертификат в ваше хранилище ключей (через keytool) и используйте это хранилище JKS.
2. Использование самозаверяющего сертификата для этого сервера напрямую.
Вероятно, это проще всего, если у вас только один сервер.
В этом случае выполните процедуру, описанную в этого ответа , и импортируйте сертификат, экспортированный с помощью -export, в доверенное хранилище вашего клиента (или в браузер).
Последний вопрос в ссылке verisign.речь идет о двух сертификатах, т. е. SSL-сертификате и цифровом сертификате.Где SSL-сертификат и цифровой сертификат соответствуют описанному выше сценарию?
Не совсем верно.Я не могу найти, где говорится о «цифровом сертификате».Строго говоря, не существует такого понятия, как «сертификат SSL», хотя выражение более или менее всегда означает «сертификат X.509, используемый для SSL / TLS».
Вы можете использовать сертификаты X.509 для других целейчем SSL / TLS и использовать SSL / TLS с другими типами сертификатов.Наиболее распространенным является X.509 с SSL / TLS.
«Цифровой сертификат» может также охватывать более широкую категорию, например, сертификаты OpenPGP также можно использовать для SSL / TLS (см. этот ответ , например).Существуют также Сертификаты атрибутов , которые даже не содержат открытого ключа (не читайте о них, пока вы действительно не поймете, что такое сертификаты X.509, в противном случае вы будете более запутаны).
Я предполагаю, что Verisign будет использовать «сертификат SSL» для обозначения сертификатов X.509 для использования с SSL и, возможно, «цифровых сертификатов» для сертификатов X.509 и для других целей, таких как e-подпись / шифрование почты.И то, и другое будет в контексте PKI (установленной Verisign).