Is it possible to use a keystore from a CA which is used to sign JARs to also be used to sign CSRs in order to create SSL certificates

Question

I have a jks keystore provided by a CA which is used to sign JARs. However, I would like to host some internal applications over HTTPS and so need to create an SSL certificate so that data can be encrypted over HTTPS. However, in order to avoid untrusted certificate/unknown host warnings in the browser, I was wondering if I could use the jks keystore used to sign JARs to also sign my CSR in order to create an SSL certificate.

So far I have managed to do the following:

1. Generate a certificate and private key pair using java keytool to create a JKS file, i.e.

   keytool -genkeypair -dname "CN=****, OU=****, O=****, L=****, ST=****, C=**" -validity 1000 -alias mykeystore -keypass ***** -keystore mykeystore.jks -storepass *****

*'s above are replaced with actual values

2. Create a CSR using the java keytool with the JKS from step 1 as input

   keytool -certreq -alias mykeystore -file mykeystore_csr.pem -keypass ***** -keystore mykeystore.jks -storepass *****

3. Convert CA JKS keystore to PKCS using keytool

   keytool -importkeystore -srcstoretype jks -srckeystore cakeystore.jks -srcalias caalias -srcstorepass ***** -srckeypass ***** -deststoretype pkcs12 -destkeystore cakeystore.p12 -destalias caalias -deststorepass ***** -destkeypass *****

4. Convert CA PKCS to PEM using OpenSSL

   openssl pkcs12 -in cakeystore.p12 -out cakeystore.pem

5. Convert CA PEM to CRT using OpenSSL

   openssl x509 -outform der -in cakeystore.pem -out cakeystore.crt

At this point I was hoping to be able to use either cakeystore.pem and/or cakeystore.crt to be able to sign mykeystore_csr.pem (from step 2 above) which could then be converted back to JKS to be used as the CA signed SSL certificate

Is this possible? Any ideas or suggesstions would be very appreciated.

Thanks

Answer 1

Nitpick: issuing a cert is NOT signing the CSR. If you look at the contents of a CSR and the contents of a cert, they are different -- although the single most important field in the cert, the publickey, does come from the CSR, and the subject name may do so.

To validly sign/issue certs, you must have an 'intermediate CA' cert with BasicConstraints specifying CA:true and KeyUsage (if used, which it usually is) specifying at least keyCertSign, and matching privatekey. See What prevents a fake ssl certificate chain and the security.SX links there.

OpenSSL doesn't actually enforce these restrictions while issuing (although it mostly does while validating); with the PEM-formatted cert and privatekey file(s) you can issue a cert using either the very basic functionality of the x509 subcommand with -req -CA/-CAkey options, or the slightly more complete ca subcommand, documented on their respective man pages on your system or on the web (numbered releases to date under commands, development 'master' under man1).

x509 -req -CA* ... just reads a CSR, formats a cert with selectable validity length and optionally configured extensions (see the man) and signs it with the CA key, setting the CA cert as the parent cert (always Issuer and optionally AKID). ca does the same with more flexible options for extensions, and in addition maintains a simple 'database' (two files and a directory) of issued certs which can be used for other CA-related functions like issuing CRLs and/or OCSP responses (ditto).

But if you (or rather any of your systems) then use such a certificate, any standard-conforming peer will reject the cert as invalidly issued. Depending on the peers, you can sometimes disable or override cert checking so that the invalid cert is accepted, but if you don't want security you might as well just turn off SSL/TLS in the first place and save time and effort.

If the CA involved is internal to your organization they may be willing to trust you with a cert-signing (sub-CA) cert, as long as you take precautions to prevent any misuse of your sub-CA that might endanger any of the other operations of the organization. OTOH if this is a public CA like Verisign or GoDaddy, issuing you a sub-CA cert means they are putting their entire business in your hands because any misuse of your sub-CA can put them out of business; for someone who needs advice in basics from strangers on the Internet that's not going to happen.