What is the purpose of a .jks keystore?

Question

I've been asked to create a jks keystore based on a certificate we had created. I've read a bit on the topic, but I'm still confused on a few items:

Is the private key of a certificate supposed to be stored in a .jks keystone?

If yes - where does this get entered in? Using the keytool, it doesn't require one for creating a jks file.

If no - what is the purpose of a jks file? Why would my application need it instead of just reading in a certificate directly? And why does the keytool require a password to create a jks if it just contains a public key?

Severe

Answer 1

Is the private key of a certificate supposed to be stored in a .jks keystone?

Yes, if you own the certificate and it is stored there.

If yes - where does this get entered in? Using the keytool, it doesn't require one for creating a jks file.

That's because you can also use it as a truststore, which only contains trusted certificates.

To get the private key in there you will need to first convert it and its certificate to a PKCS#12 file using openssl, as answered in numerous questions here such as this.

If no - what is the purpose of a jks file? Why would my application need it instead of just reading in a certificate directly?

Because your application also needs the private key of the certificate.

And why does the keytool require a password to create a jks if it just contains a public key?

A keystore has a password because it is a security-related entity.

Mitch

Answer 2

The purpose of a key store is to protect the privacy and integrity of cryptographic keys using password-based algorithms. Privacy means that the keys are kept secret; they can only be used by someone who knows the password; this is useful for private keys and secret keys. Integrity means that alteration of the keys can be detected by someone who knows the password; this is useful for public keys and secret keys.

Whether you should include the private key or not depends on what you are trying to do. If you are creating a key store for your server so that it can authenticate itself to clients, for example, then it should contain the private key. If you created a self-signed certificate, and want to give clients a key store so that they can authenticate your service, then it should not contain the private key.

If you have a pre-existing key pair, and want to import it to a JKS format key store, the easiest way might be to use OpenSSL to create a PKCS #12 format key store, then use keytool to convert that to a JKS key store. Normally, keytool expects to do key pair generation itself, and so the private key will be stored there from the beginning.

You should verify the integrity of a public key or a certificate before you use it to encrypt a message or verify a signature. Otherwise, an attacker can replace the key with one he owns and act as a man in the middle. If you simply read a public key from a file, you don't know it really belongs to your intended recipient. But if you store a password-based message authentication code with the public key, you can ensure that it hasn't been tampered with.

Billbug

You can't verify a public key, but you can verify a certificate that contains one. SSL does that automatically. You wouldn't store a public key by itself not a file: you would store the certificate, which provides authentication as well as tamper-evidence. – Mitch

@EJP I know that you know what you're talking about, although your comment is poorly worded. But I'm explaining—to someone who doesn't know—why you'd need to store a certificate in a password-protected key store, rather than a plain file. – Billbug

My wording seems perfectly clear to me, and a distinct improvement over the incorrect wording in your answer. – Mitch

"You can't verify a public key,"—I never said you could—"but you can verify a certificate that contains one." Sure... with another public key. PKIX path validation is one way to do that. "SSL does that automatically." Except for the root; that would be useless. "You wouldn't store a public key by itself [in] a file:"—many SSH implementations do precisely this—"you would store the certificate, which provides authentication as well as tamper-evidence." A trust anchor's embodiment in a certificate doesn't protect its integrity. You need something extra, like a key store, file permissions, etc. – Billbug

You said, and I quote verbatim: 'you should verify the integrity of a public key'. Please explain. SSH is irrelevant to a question about keystores, as it doesn't have a certificate infrastructure at all. – Mitch