Can't generate a keystore to sign, what is the difference between keystool and oppen

Question

I am trying to generate a key and CSR that I can sign using my root key. I've found two approachese and can't figure out whats the difference:

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

or use openssl to generate a 'key'

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

What's the difference between the two? can't both be used to in when i sign the certificate?

Answer 1

TLDR: It's the file format(s) used locally; the CSR itself is basically the same.

First, an aside: issuing a certificate is NOT signing the CSR. The cert can be based on a CSR, but it is the cert that is signed by the Certificate Authority's key, which may or may not be a root CA key.

Java:

keytool -genkeypair generates a keypair and a 'dummy' (self-signed) certificate for that keypair, and stores them (together) in a keystore. Even though the self-signed cert will often be replaced by a 'real' CA-issued cert (and usually chain) before use, it is created because the Java API for KeyStore requires it; that's why -genkeypair prompts for several name fields (unless you specify -dname). Java supports several kinds of keystores; through Java 8 the default is a JKS-format file although this is planned to change in Java 9. One JKS file can contain multiple entries, each containing a key plus cert chain combination for yourself OR a 'trusted' cert, usually a CA root, for others. A privatekey in a JKS is encrypted using a password, and the whole JKS is also protected (MACed) using a password. These are designated keypass and storepass and can be different, but by default are the same, hence the prompt Enter key password for <alias> (RETURN if same as keystore password)

keytool -certreq creates a CSR for the key in the keystore, using by default the Subject name from the dummy cert in the keystore, although you can specify -dname to alter it.

If you then get a cert issued by a CA using that CSR, you can use keytool -importcert to install it, with any needed chain cert(s), into the keystore. Java programs then use the keystore entry to do things like implement a TLS (including HTTPS) server. However, you cannot easily get the private key out of a JKS keystore and use it for anything other than Java programs. (You can convert to a PKCS12 keystore, which can be more flexibly used.)

OpenSSL:

openssl genrsa generates only the keypair (no cert) and writes it to a file that contains only the private key, in PEM format by default but you can specify -outform der instead; this uses PKCS1 CRT-format, which effectively includes the publickey. By default this file is not encrypted, although for PEM (not DER) you can specify a cipher to have it password-encrypted -- but using OpenSSL's 'legacy' PBE, which is poor. PEM files are text-based and can be partly read, at least enough to identify them, with a text editor or cat etc instead of a special program like keytool.

openssl req -new creates a CSR for the given keypair; it normally prompts for the name fields, similar to keytool -genkeypair, plus a few others. The name field prompting is controlled by the config file you use, which can be the default one or one you specify with -config, and you can thus change from the standard list if you want, or you can use -subj on the command line to override it. OpenSSL is capable of including extensions and some 'attributes' like challengePassword in the CSR, which Java does not, but few if any CAs accept these fields anyway.

When you get back a cert from the CA, OpenSSL programs usually require you to provide the privatekey and the matching cert and usually the chain cert(s) in some combination of files -- sometimes one, sometimes two, sometimes three or even more. You may be responsible for keeping track of which key goes with which cert (which can often be done with suitable filenames) and if you have multiple key-and-cert combinations you are always responsible for keeping track of which is which (ditto). If you want to use this key and cert in non-OpenSSL programs, you need to convert to the more standard PKCS12 form, which combines key and certs in one file.

You can use the newer (but more complex) openssl genpkey instead of genrsa; this writes the privatekey file in a the 'new' (since about 2000!) PKCS8 format, again in PEM by default but optionally DER. Again by default this is not encrypted, but if you select encryption the PKCS8 PBE is better than the 'legacy' PBE used by genrsa. You can also convert a legacy privatekey file to PKCS8 with openssl pkcs8 -topk8 or (since 1.0.0) openssl pkey. OpenSSL programs that read privatekeys can read either legacy or PKCS8 transparently as long as you stay with the default PEM.

You can also combine the steps into one with openssl req -newkey rsa[:bits] [-keyout file] .... The bracketed items can be supplied from the config file, and for modern versions (since 1.0.0 in 2010) this uses the new PKCS8 file format, and it defaults to encrypting the file. See https://security.stackexchange.com/questions/93417/what-encryption-is-applied-on-a-key-generated-by-openssl-req .