From my understanding, the Java keystore contains certificate information, but this information is public (i.e. other machine certificates which you want the local machine to trust).

Is there something else besides this that I am missing? What would be the risk in protecting the keystore with a weak password?


I just realized I might have been referring to the truststore in this question. Apparently the keystore also includes private keys. If you can confirm this, then I can easily see what the issue of using a weak password to protect it would be.

3 Answers 3


the Java keystore contains certificate information

To be more precise it contains public keys or key pairs (public and private key). The keystore is protected by a password and every private key is also protected by a password. However you are able to change or remove passwords. It's up to you. A Java keystore is like a detached keystore of a web browser i.e.

Mozilla -> Edit -> Preferences -> Advanced -> Certificates,
Chrome -> Settings -> Advanced Settings -> HTTPS/SSL

A Certificate Manager of such manages your certificates, peoples public keys, server or Certificate Authority certificates which are also public keys. They are stored in the keystore of a browser.

but this information is public (i.e. other machine certificates which you want the local machine to trust)

Public are only keys that don't need any protection, they are the public keys. Private keys are not public and protected by a password.

You decide when to use the keys and when stolen it is not easy extract informations from. So a keystore is a security enchancement.

But you speak generally about the level of trust, or Trust metrics.

To do this you need to know, that a private keys can theoretically also be guessed, so your security is not 100%. A todays supercomputer listed at Top500 Supercomputer Sites with 33,862.7 Tera Flops/s could bruteforce you private key. Theoretically, your computer/laptop can be stolen or your keystore can be stolen and your passwords can be read by a trojan.

You will end up asking, how high is the risk if my keystore would be stolen and decrypted and what can I do to prevent it. This is often also a question of effort and price.

If your risk is high, then you need to store your keystore on a detached disk (i.e. pen drive), use long complex passwords and use a special protected machine to connect from.

  • Thanks for the answer. So every private key inside it is protected by a password then, this makes sense. How can I see/edit these passwords? Commented Jul 13, 2014 at 17:34
  • There is a command line utility named keytool. Use keytool -list. Maybe also a GUI utility.
    – user36486
    Commented Jul 13, 2014 at 17:59
  • That only lists the contents of the keystore with not enough detail to see the passwords of the single entries however. Commented Jul 14, 2014 at 7:51
  • In the meantime, bounty awarded. Commented Jul 14, 2014 at 9:36
  • Thanks for the award. Even in verbose '-v' mode you wont see the data, you need to export each entry to see them. The handling with the keytool isn't easy, here is a documentation link
    – user36486
    Commented Jul 14, 2014 at 12:56

If you are talking about the truststore, the risk isn't that someone will see or steal the certs in the truststore. The risk is that someone will add a certificate into the store which you do not want to trust. The store should be protected first protected by the OS permissions. The password is an additional protection.

  • Actually, after reading your answer, I have updated the question. I might have made some confusion in there. Commented Jul 2, 2014 at 13:05

I think it is important to have a strong password when you keep a chain of certificates in the keystore in order to perform a client-side authentication. Some servers, i.e: banking servers need client-authentication to set up a trustful connection: "proof me that you are the client that I think you are". You'll want to put these certificates in the keystore so other applications can't get a hold of them. I'm thinking in terms of a mobile platform like Android, for example. But correct me if I'm wrong.

Public certificates are usually not stored in keystores, in my experience that is.

Hope it is of help.

  • Do you mind explaining the Android example a bit further? Commented Jul 2, 2014 at 13:06
  • Android uses the BouncyCastle keystore format (BKS). Typically banking applications require client authentication. ....
    – 4oxer
    Commented Jul 2, 2014 at 13:57
  • This means that the client connecting to the server has to prove that he is who he pretends to be; This is done by creating a secure connection which is built on the fact that the server will check the certificate that the client provides to the server (the server needs to resolve the certificate chain) The android keystore is protected by a password and contains your private keys and/or certificates.
    – 4oxer
    Commented Jul 2, 2014 at 13:57
  • If this is a weak password a hacker can extract the certificate and use social engineering for example recovering the private key for the certificate. The hacker can than impose as the client and setup an "untrusted" connection.
    – 4oxer
    Commented Jul 2, 2014 at 13:58
  • But all this aside, why not just use a strong password? :D
    – 4oxer
    Commented Jul 2, 2014 at 13:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .