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?
Truststore Password--The password for the truststore used by the client. By default, the password for the GlassFish truststore is already specified. The password is changeit . NOTE: When specified, this password is stored in a WSIT configuration file in clear text.
You cannot create a keystore with a blank password with keytool since a while, but you can still do it programmatically.
The default server password is changeit . The keytool application is included in the Java developer kit and is not part of IBM® UrbanCode Deploy. The default server alias is server .
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: 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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With