如何将JKS转换为Docker Registry cert / key？

Question

I am trying to set up a secure Docker Registry on two VMs (for HA) and have a question about setting up the SSL. According to that link in the docs, I need to have a certs directory with two files in it:

• registry.crt - the CA cert
• registry.key - ??? (private key?)

I have been given a Java JKS (keystore) that contains in it a wildcard CA cert that will work for these VMs. I was able to successfully export the cert out of the keystore like so:

keytool -export -alias certalias -file registry.crt -keystore mycerts.jks

So far so good: I have registry.crt . However a few related questions/concerns are preventing me from completing this setup:

• What is the *.key file, how is it different than the cert, and how do I extract it from the JKS?
• Where is Docker/Registry expecting this certs directory on each VM? Perhaps /home/myuser/ ? Is this location configurable?!?
• As the link explains, a special additional action is required if your CA cert is an " intermediary " cert. How can I tell if my cert is intermediary or not?

Answer 1

There are really three questions here. You should probably ask different questions. I don't know the answer to your second one but will answer for the other two.

---

In simple terms in the context of SSL the client initiates a secure connection using the public key contained in the certificate. Only the server who possesses the according (private) key can answer and therefore establish the connection. (There's a lot more going on.)

The short regarding the keystore is: Do yourself a favor and use a tool like KeyStore Explorer . No affiliation, I just like the tool. Exporting the private key with keytool is not that simple. As far as I know you cannot export the private key directly. You can however export to PKCS12 and use other tools like OpenSSL from there :

keytool -importkeystore -srckeystore existing-store.jks -destkeystore new-store.p12 -deststoretype PKCS12

If you only have one self-signed certificate (signer is the same as subject), you don't need to worry about intermediaries. An intermediate certificate means that the certificate signed by the CA that signed your certificate is itself signed by yet another CA.

CA 0 (signed by CA 0) - well known certificate, self-signed
 \_ CA 1 (signed by CA 0) - intermediate certificate
     \_ Your Cert (signed by CA 1)

In order to verify the integrity of your certificate the whole chain must be known to the client. Usually only the CAs at the very top are distributed in browsers and operating systems (CA 0) so you need to publish the certificates "in between"—the intermediaries (CA 1).