Import certificate as PrivateKeyEntry

Question

I am installing SSL on a Tomcat server and am following these instructions from the issuer https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&actp=CROSSLINK&id=SO16181 and it states:

Verify the following information:

The SSL certificate is imported into the alias with the "Entry Type" of 
PrivateKeyEntry or KeyEntry.  If not, please import the certificate into 
the Private Key alias.

When I import the certificate (tomcat) I am using:

keytool -import -trustcacerts -alias your_alias_name -keystore your_keystore_filename
-file your_certificate_filename

but when I do so it imports as trustCertEntry

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 3 entries

primaryca, Jul 26, 2014, trustedCertEntry,
Certificate fingerprint (SHA1): <snip>
tomcat, Jul 26, 2014, trustedCertEntry,
Certificate fingerprint (SHA1):  <snip>
secondaryca, Jul 26, 2014, trustedCertEntry,
Certificate fingerprint (SHA1):  <snip>

How can I make alias tomcat import as PrivateKeyEntry?

Dube

You chain does not need primaryca. The server should send the server certificate and any intermediate certificates needed to build a path to the trusted authority. Its up to the client to trust the authority or primaryca. There's nothing you can do if the client does not trust the authority or primaryca (other than ask them to trust it). – Woodenware

Have clarified - this refers to the certificate with the alias tomcat which is the actual certificate for the server and not either of the ca certificates – Dube

This seems relevant: Java keytool: import private key into Java key store (JKS). – Woodenware

That does not work, you cant do it directly! xinotes.net/notes/note/1007 – Switzerland

Answer 1

Get rid of the -trustcacerts option. It isn't a CA certificate. It's your certificate. And use the same alias the private key already had.

Aeciospore

Leaving that off didn't make a difference for me. This isn't necessarily the only problem. – Hairball

@ToddWilcox I didn't say it was the only problem. I gave a second requirement. Did you satisfy it? – Aeciospore

Answer 2

You try to add certificate and expect that it will be private key - its confusion between two different things.

Generally, when you create keystore (.jks) it include the private key inside. If its empty (deleted) you should generate bundle (.p12 file) from your key and certificates.

In order to create new free key and certificate you can use this this implementation of openSSl https://zerossl.com.

Then, you've got a key and certificate that you should generate (.p12) bundle file from them: (on linux machine)

openssl pkcs12 -export -in [filename-certificate] -inkey [filename-key] -name [host] -out [filename-new-PKCS-12.p12]

Now, just add the bundle file (.p12 file) to a keystore (.jks) by executing the following command:

keytool -importkeystore -deststorepass [password] -destkeystore [filename-new-keystore.jks] -srckeystore [filename-new-PKCS-12.p12] -srcstoretype PKCS12

Prowess

The openssl PKCS12 export may require you to provide a password. You can supply it via command line with -password pass:YourPasswordHere. You'll need to supply it to the keytool import with -srcstorepass YourPasswordHere. – Nation

Answer 3

These CA guidelines are a bit misleading. @EJP rightly said that you shouldn't use -trustcacerts for your certificate.

In addition, this CA document suggests to import the primary and intermediate CA certificates in separate operations, which should give you a result like this:

primaryca, Jul 26, 2014, trustedCertEntry,
Certificate fingerprint (SHA1): <snip>
secondaryca, Jul 26, 2014, trustedCertEntry,
Certificate fingerprint (SHA1):  <snip>
tomcat, Jul 26, 2014, PrivateKeyEntry,
Certificate fingerprint (SHA1):  <snip>

Unfortunately, importing the CA certificates in your keystore like this is pointless. (It would be useful in a truststore, but the CA you're using is probably already in the default truststore.)

It is useful to have the CA certificates for your certificate in the keystore indeed, to present a complete certificate chain when intermediate certificates are required. However the keymanager (unless perhaps a custom implementation) will not build the chain for you, even if it find suitable CA certificates next to your End-Entity Certificate (in PrivateKeyEntry).

You need to import those certificates together, as a chain, against the entry where your private key is. To do so, concatenate the certificates together in a text file (PEM-encoded), your server cert first, followed by the cert used to issue it, and so on. Then, import that file into your keystore using that private key alias. (This is exactly the same problem as in this question, but with a server certificate.)

(I'm not sure whether your CA gives you your cert file as a chain already, but generally, you get at least your cert only in one file, and the intermediate CA certs in another. The document you link to seems misleading because they make no mention of more than one block between --BEGIN/END CERT--, yet somehow their example screenshot has a certificate length of 4 against that single alias.)

As @jww pointed out in a comment on your question, you don't need the "root" CA certificate (the one that is self-signed) in this chain, since either your client trusts it already, or it has no reason to trust it when you send it. It's not wrong to have it in your chain, but it's pointless, and might add a bit of network overhead.

Ungenerous