Do you not need a password to access a truststore (made with the java keytool)?

Question

I just created a truststore with the java keytool (for server authentication of a server that does not have a CA cert). However I just noticed something strange. I am starting my client like this:

java -Djavax.net.ssl.trustStore=<PATHSTUFF>/client.keystore -classpath <STUFF> Client

(Note: there is NOT a password specified)

The above call works.

---

However when I try this:

java -classpath <STUFF> Client

It does not work. (Obviously it does not work it requires the truststore).

---

I was expecting to need to pass in this option (but I did not):

-Djavax.net.ssl.trustStorePassword=mypass

---

Question: Do you not need a password to access a truststore? Is the password just for modification? What about a keystore?

Levitan

@Pascal, yes. The server I am using does not have a CA cert so it needs a truststore so that it can do ssl authentication for the server. – Levitan

I also don't understand why a password is needed for the TrustStore, which is the client part of the SSL. Specifically, when a CA isn't involved. Have you managed to resolve this? – Agripina

Answer 1

The password is used to protect the integrity of a keystore. if you don't provide any store password, you can still read the contents of the keystore. The command keytool -list demonstrates this behavior (use it with an empty password).

Interstellar

@Levitan Yes, the integrity is not checked but, still, you can access the keystore. – Interstellar

This answer is about the KeyStore but the main question is about the TrustStore. I'm confused. – Agripina

@Agripina The truststore and keystore have the same format and both are accessed via keytool from CLI. So the answer applies to both keystore and truststore. – Doubtful

Answer 2

In addition to pascal-thivent's excellent answer:

The keystore password has two purposes - if not supplied, keytool refuses to let you replace the contents of the store with new contents e.g. by deleting existing or adding new certificate entries.

Of course if you have write-access to update the keystore file using keytool (it's not setuid), you could replace the contents using another tool which didn't check the password. And we know that the store and its format is readable without a password, so presumably we can write what we want there.

That's where the verification password comes-in. When the store entries are written-out, the supplied store password is used to compute a digest of the store-contents, as salted by the password. This is a one-way hash/digest, so without the password, you cannot verify whether the store contents have been tampered with or not. Equally, someone malicious who does not know the password also cannot modify the store's contents and produce the digest-hash that would be produced by that password.

That's why when you supply no-password, keytool just warns you that it can't verify that the store has not been tampered with. If you provide an invalid password, or the store has been tampered with, you will get a different message:

Enter keystore password:
keytool error: java.io.IOException: Keystore was tampered with, or password was incorrect

keytool was unable to re-create the existing hash digest based on the current store contents and the password you supplied, so either the password is incorrect, or the keystore is compromised - keytool cannot tell, but it assumes that you or the software reading the store knows.

Note that whilst the term keystore is used generally, it refers equally to keystores and truststores. Less-generally, a keystore is more often an identity store and contains identities and their secret, private keys, as used e.g. by a server running HTTPS. A truststore more often contains only public keys and no private keys, so no secrets, but is important to determine what identities a client trusts.

Morette

Really nice answer. I also noticed that different store types treats the password in different ways. While providing no password for JKS type just results in unavailability to check the store integrity, providing no password for PKCS12 keystore results in empty list (when use keytool -list) so that there is no chance to use the store if you do not know the password. – Iveyivie

Answer 3

By default, the JRE trust store password is "changeit". If you want to change the default trust store (cacerts) password programmatically using Java, then please go through this link.

Echinoid

Answer 4

Your point is valid. The decision to password-protect a truststore depends on the security context and the environment in which it operates.

In scenarios where the truststore is in a trusted environment with restricted access, and it's configured as non-modifiable or read-only, the need for password protection may be diminished. If unauthorized access to the truststore is improbable or practically impossible, and the integrity of the truststore can be guaranteed, one might opt not to use a password.

However, it's crucial to understand potential risks, such as scenarios where a hacker gains access to the truststore and can manipulate it to introduce new certificates. Even in read-only setups, there may be vulnerabilities, like modifying container configurations and volume replacement. That way he can add a new certificate to the truststore. This new certificate can trick your application into trusting a rogue server set up by the hacker.

In contrast, as described in other responses, protecting the keystore is a must as it contains private credentials.

Graner

Answer 5

If you do not specify a truststore, the default one is used instead. I assume, you get an error, that you'll need to specify a truststore in order to trust the host you request? The default truststore resides in $JAVA_HOME/lib/security/jssecacerts.

Rodgerrodgers

Hi bfoo, yeah I knew that is where it defaults however that does not answer my question. Clearly the default is not working and the one I specified is. My question is: In order to read a truststore do you need a password? Is there a default password? – Levitan