glassfish
  1. glassfish
  2. GLASSFISH-18173

Support relocation of keystore and truststore (configure -Djavax.net.ssl.trustStore)

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.1.2
    • Fix Version/s: future release
    • Component/s: admin
    • Labels:
      None

      Description

      1. move keystore.jks and cacerts.jks to /tmp
      2. modify the -Djavax.net.ssl.keyStore, -Djavax.net.ssl.trustStore to point to /tmp/keystore.jks and /tmp/cacerts.jks respectively
      3. Cannot start the server as it keeps prompting the master password

      asadmin start-domain domain1
      Enter master password (3) attempt(s) remain)>
      Sorry, incorrect master password, retry
      Enter master password (2) attempt(s) remain)>
      Sorry, incorrect master password, retry
      Enter master password (1) attempt(s) remain)>
      Number of attempts (3) exhausted, giving up
      Command start-domain failed.

      But if I copy cacerts.jks back to domains/domain1/config, then I can start the server with https working properly with the certificate in /tmp/keystore.jks.

        Activity

        Hide
        Tom Mueller added a comment -

        The root cause of this issue is the LocalServerCommand.getJKS method, which has a hardcoded reference to

        new File(new File(serverDirs.getServerDir(), "config"), "cacerts.jks")

        for the file to use to verify the validity of the master password. This is incorrect for several reasons.

        1) the certs file the user is using might not be called cacerts.jks
        2) it might not be in the config directory (as pointed out by this issue)

        A better way to verify the master password is to check it against the domain-passwords file the location of which is not configurable by the user.

        Note: the change master password command is also hardcoded to reference the keystore.jks and cacerts.jks files in the domain's config directory. As least this command does not support having these files in another location.

        However, the security guide, in the section that talks about generating a certificate (http://docs.oracle.com/cd/E18930_01/html/821-2435/ablqz.html#), has the following:

        "Always generate the certificate in the directory containing the keystore and truststore files. The default is domain-dir/config."

        The statement that the default is domain-dir/config would seem to imply that it is possible to store the keystore and truststore files somewhere else. However, the code in at least these two places does not support that.

        Show
        Tom Mueller added a comment - The root cause of this issue is the LocalServerCommand.getJKS method, which has a hardcoded reference to new File(new File(serverDirs.getServerDir(), "config"), "cacerts.jks") for the file to use to verify the validity of the master password. This is incorrect for several reasons. 1) the certs file the user is using might not be called cacerts.jks 2) it might not be in the config directory (as pointed out by this issue) A better way to verify the master password is to check it against the domain-passwords file the location of which is not configurable by the user. Note: the change master password command is also hardcoded to reference the keystore.jks and cacerts.jks files in the domain's config directory. As least this command does not support having these files in another location. However, the security guide, in the section that talks about generating a certificate ( http://docs.oracle.com/cd/E18930_01/html/821-2435/ablqz.html# ), has the following: "Always generate the certificate in the directory containing the keystore and truststore files. The default is domain-dir/config." The statement that the default is domain-dir/config would seem to imply that it is possible to store the keystore and truststore files somewhere else. However, the code in at least these two places does not support that.
        Hide
        Tom Mueller added a comment -

        There are several functions within GlassFish that depend on the names and locations of the keystore and truststore files, including:

        • domain creation (PEDomainsManager)
        • change-master-password
        • DAS and instance startup (GFLauncher)
        • instance synchronization (hardcoded in config-files file)

        In order to support moving and/or renaming these files, at least these places would need to be fixed.

        Shing Wai reports that this was supported in 2.x, however it isn't clear what "this" is. Is it just that the javax.net.ssl.trustStore JVM property could be set, but these other functions do not handle it properly - or did everything work?

        Show
        Tom Mueller added a comment - There are several functions within GlassFish that depend on the names and locations of the keystore and truststore files, including: domain creation (PEDomainsManager) change-master-password DAS and instance startup (GFLauncher) instance synchronization (hardcoded in config-files file) In order to support moving and/or renaming these files, at least these places would need to be fixed. Shing Wai reports that this was supported in 2.x, however it isn't clear what "this" is. Is it just that the javax.net.ssl.trustStore JVM property could be set, but these other functions do not handle it properly - or did everything work?
        Hide
        Tom Mueller added a comment -

        I did some experimenting with GF 2.1.1 and here is what I found.

        1. I moved the cacerts.jks and keystore.jks files to domains/domain1/tmp and edited the JVM options to point to them. Then started the domain and it started fine (this confirms the initial premise in the bug).

        2. I stopped the domain and ran change-master-password. It prompted for the new password and appeared to run successfully - no error messages or log messages. Then I tried starting the domain. This time it prompted for the admin password and the master password. I entered an incorrect master password and it correctly detected that and the domain did not start. Next I started the domain again and entered the correct password, but the domain still did not start but it produce a different log message saying:

        Caused by: java.lang.IllegalStateException: Keystore was tampered with, or password was incorrect

        So clearly, the keystore in the new location did not have it's password changed by change-master-password.

        3. I created a cluster that has a config with the keystore and truststore JVM options pointed at the new location. Instances in that cluster failed to start because the keystore.jks and cacerts.jks files were not synchronized from the DAS. The instances reported a file not found error.

        So this confirms that GF 2.1.1 really doesn't support having the keystore or truststore files moved or renamed, at least it doesn't support this fully.

        IMHO, this is not a regression.

        Show
        Tom Mueller added a comment - I did some experimenting with GF 2.1.1 and here is what I found. 1. I moved the cacerts.jks and keystore.jks files to domains/domain1/tmp and edited the JVM options to point to them. Then started the domain and it started fine (this confirms the initial premise in the bug). 2. I stopped the domain and ran change-master-password. It prompted for the new password and appeared to run successfully - no error messages or log messages. Then I tried starting the domain. This time it prompted for the admin password and the master password. I entered an incorrect master password and it correctly detected that and the domain did not start. Next I started the domain again and entered the correct password, but the domain still did not start but it produce a different log message saying: Caused by: java.lang.IllegalStateException: Keystore was tampered with, or password was incorrect So clearly, the keystore in the new location did not have it's password changed by change-master-password. 3. I created a cluster that has a config with the keystore and truststore JVM options pointed at the new location. Instances in that cluster failed to start because the keystore.jks and cacerts.jks files were not synchronized from the DAS. The instances reported a file not found error. So this confirms that GF 2.1.1 really doesn't support having the keystore or truststore files moved or renamed, at least it doesn't support this fully. IMHO, this is not a regression.
        Hide
        Tom Mueller added a comment -

        Changing this to be an RFE targeted for a future release. Excluding from 3.1.x releases.

        Show
        Tom Mueller added a comment - Changing this to be an RFE targeted for a future release. Excluding from 3.1.x releases.
        Hide
        Shing Wai Chan added a comment -

        This is a regression on the DAS.

        Show
        Shing Wai Chan added a comment - This is a regression on the DAS.

          People

          • Assignee:
            kumara
            Reporter:
            Shing Wai Chan
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: