Невозможно создать хранилище ключей для подписи, в чем разница между keystool и oppen

Question

Я пытаюсь сгенерировать ключ и CSR, которые я могу подписать с помощью моего корневого ключа. Я нашел два approachese и не могу понять, Что разница:

1) you can generate a keystore using key tool and then it's CSR. 
keytool -genkey -alias [enter_alias_name] -keyalg RSA -keystore [enter_keystore_name] -keysize 2048 
2)keytool -certreq -alias [alias_name] -file certreq.csr -keystore 

или использовать OpenSSL для создания «ключ»

1)openssl genra -out device.key 2048 
2)openssl req -new -key device.key -out device.csr 

В чем разница между ними? не могут использоваться оба, когда я подписываю сертификат?

Answer 1

TLDR: формат файла (ов), используемый локально; сама КСО в основном такая же.

Во-первых, выдача сертификата НЕ подписывает CSR. Сертификат может быть основан на CSR, но это сертификат, подписанный ключом центра сертификации, который может быть или не быть корневым ключом CA.

Java:

keytool -genkeypair генерирует пару ключей и «пустышку» (самоподписанный) сертификат для этой пары ключей, и сохраняет их (вместе) в хранилище ключей. Несмотря на то, что самозаверяющий сертификат часто заменяется «реальным» сертификатом CA (и обычно цепочкой) перед его использованием, он создается, потому что для него требуется Java API для KeyStore; поэтому -genkeypairпредлагает несколько полей имени (если вы не указали -dname). Java поддерживает несколько типов хранилищ ключей; через Java 8 по умолчанию является файлом формата JKS, хотя это планируется изменить на Java 9. Один файл JKS может содержать несколько записей, каждый из которых содержит комбинацию ключей плюс цепочку сертификатов для себя или «доверенный» сертификат, обычно корень СА, для других. A закрытый ключ в JKS зашифрован с использованием пароля, а весь JKS также защищен (MACed) с использованием пароля. Они обозначены keypass и storepass и могут быть разными, но по умолчанию одинаково, поэтому подсказка Enter key password for <alias> (RETURN if same as keystore password)

keytool -certreq создает CSR для ключа в хранилище ключей, используя по умолчанию имени Темы из фиктивной CERT в keystore, хотя вы можете указать -dname, чтобы изменить его.

Если вы затем получите сертификат, выданный ЦС, используя эту CSR, вы можете использовать keytool -importcert, чтобы установить его с любыми необходимыми цепными сертификатами в хранилище ключей. Затем программы Java используют запись хранилища ключей для выполнения таких операций, как реализация сервера TLS (включая HTTPS). Однако вы не можете легко получить секретный ключ из хранилища ключей JKS и использовать его для чего-либо, кроме программ Java. (Вы можете конвертировать в PKCS12 хранилище, которое может быть более гибко использоваться.)

OpenSSL:

openssl genrsa генерирует только пары ключей (не CERT) и записывает его в файл, который содержит только закрытый ключ, в формате PEM по умолчанию, но вы можете указать вместо этого -outform der; это использует CRT-формат PKCS1, который эффективно включает публикацию. По умолчанию этот файл не зашифрован, хотя для PEM (не DER) вы можете указать шифр, чтобы он зашифровал пароль, но используя OpenSSL 'legacy' PBE, который является плохим.Файлы PEM основаны на тексте и могут быть частично прочитаны, по крайней мере, достаточно для их идентификации, с текстовым редактором или cat и т. Д. Вместо специальной программы, например keytool.

openssl req -new создает CSR для данной пары ключей; обычно запрашивает поля имени, аналогично keytool -genkeypair, плюс несколько других. Запрос поля имени управляется файлом конфигурации, который вы используете, который по умолчанию может быть указан по умолчанию, или, и вы можете, таким образом, изменить его из стандартного списка, или вы можете использовать -subj в командной строке для переопределения Это. OpenSSL способен включать в себя расширения и некоторые «атрибуты», такие как challengePassword в CSR, чего нет в Java, но мало, если любые CA согласны с этими полями в любом случае.

Когда вы возвращаете сертификат из центра сертификации, программам OpenSSL обычно требуется предоставить секретный ключ и соответствующий сертификат и, как правило, сертификаты цепи в некоторой комбинации файлов - иногда один, иногда два, иногда три или даже больше. Вы можете нести ответственность за отслеживание того, какой ключ идет с каким сертификатом (который может часто выполняться с подходящими именами файлов), и если у вас есть несколько комбинаций клавиш и сертификатов, вы всегда несете ответственность за отслеживание того, что (то же самое). Если вы хотите использовать этот ключ и сертификат в программах, отличных от OpenSSL, вам нужно преобразовать в более стандартную форму PKCS12, которая объединяет ключевые и сертификаты в одном файле.

openssl genpkeygenrsa; это записывает файл privatekey в формате «новый» (начиная с 2000!) PKCS8, снова в PEM по умолчанию, но, возможно, DER. Опять-таки по умолчанию это не зашифровано, но если вы выберете шифрование, то PBE PKCS8 лучше, чем «прежнее» PBE, используемое genrsa. Вы также можете преобразовать старый файл приватного ключа в PKCS8 с openssl pkcs8 -topk8 или (начиная с 1.0.0) openssl pkey. Программы OpenSSL, которые читают privatekeys, могут читать либо legacy, либо PKCS8 прозрачно, если вы остаетесь с PEM по умолчанию.

Вы также можете комбинировать шаги в одном с openssl req -newkey rsa[:bits] [-keyout file] .... Элементы, заключенные в скобки, могут быть предоставлены из файла конфигурации, а для современных версий (начиная с версии 1.0.0 в 2010 году) используется новый формат файла PKCS8, и по умолчанию он шифрует файл. См. https://security.stackexchange.com/questions/93417/what-encryption-is-applied-on-a-key-generated-by-openssl-req.