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<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):

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

Was it helpful?


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).


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: 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.

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.

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow