0

I have a very simple scenario:

public class Main {
    public static void main(String[] args) {
        System.setProperty("javax.net.debug", "ssl"); 
        System.setProperty("javax.net.ssl.trustStore", "H:/data/serverkeystore.jks");
        System.setProperty("javax.net.ssl.trustStorePassword", "somestuff");
        try {
            ServerSocketFactory ssf = (SSLServerSocketFactory) SSLServerSocketFactory.getDefault();
            SSLServerSocket serverSocket = (SSLServerSocket) ssf.createServerSocket(1337);
    ... code goes on here ...

It does not matter if I comment the line 

System.setProperty("javax.net.ssl.trustStorePassword", "somestuff");

out or if I use it. In the answers to this question, it was well described what the password is used for (even if the source information is missing there) and that if a password is not given, the integrity of the TrustStore can not be verified. So in my sample code, if you uncomment that line, Java will use the TrustStore without checking its integrity. Through my own tests, I could determine that if I give a wrong password and use the code, as shown above, that it comes to an error message (which is a desired result). I am just surprised that it is possible to omit the password and then Java apparently works with an unchecked TrustStore. Can anyone explain the initialization routine of the TrustStore with regard to my question?

As already mentioned in the question, I use my own password for the TrustStore, which differs from the standard password "changeit".

Lukas Nothhelfer
  • 261
  • 1
  • 5
  • 14
  • 1
    Because a trust store only contains certificate entries, and certificate entries aren't confidential and don't need passwords. Only key entries need to be secure, and they only occur in keystores, by definition. – user207421 Oct 25 '19 at 09:08
  • It even depends on the SPI (JCE) implementation, indeed you don't need any password to list a JKS store. Certificates aren't confidential, but you wouldn't want anyone to tamper with the list of certificates the system should trust (e.g. providing a rogue/false root CA). Indeed there should be a way to enforce trust of the truststore (the password should be validated). If you provide a wrong password, will it fail? – gusto2 Oct 25 '19 at 09:15
  • @gusto Yes it will fail, and if you don't provide a password you can't update the truststore, – user207421 Oct 25 '19 at 09:21
  • @user207421 indeed, that's expected behavior. For JKS keystores you may list entries and certificates without any password, but unable to verify the integrity. Anyway you should provide a password with your application to make sure nobody sc..wd with your truststore. – gusto2 Oct 25 '19 at 09:25
  • @user207421 Thank you for your first comment. That was already everything I needed. If you put your first comment in an answer, then I can mark it as an accepted answer (for future travelers). – Lukas Nothhelfer Oct 25 '19 at 09:26

1 Answers1

1

It even depends on the SPI (JCE) implementation, indeed you don't need any password to list a JKS store.

Certificates aren't confidential, but you wouldn't want anyone to tamper with the list of certificates the system should trust (e.g. providing a rogue/false root CA).

There should be a way to enforce trust of the truststore (the password should be validated). If you provide a wrong password, will it fail?

Yes it will fail, and if you don't provide a password you can't update the truststore

indeed, that's expected behavior. For JKS keystores you may list entries and certificates without any password, but unable to verify the integrity. Anyway you should provide a password with your application to make sure nobody sc..wd with your truststore.

gusto2
  • 11,210
  • 2
  • 17
  • 36