glassfish
  1. glassfish
  2. GLASSFISH-18175

The key-store, trust-store element in ssl protocol element are not working

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: not determined
    • Component/s: security
    • Labels:
      None

      Description

      Specifying the keystore and truststore in ssl protocol element in domain.xml are not working.
      One still pick up the keystore and truststore from jvm options.

      A sample xml snapshot is as follows:
      <protocol security-enabled="true" name="ssl-listener">
      <http default-virtual-server="server">
      <file-cache></file-cache>
      </http>
      <ssl key-store="/opscenter/security/keystore/keystore" ssl3-tls-ciphers="+SSL_RSA_WITH_RC4_128_MD5,+SSL_RSA_WITH_RC4_128_SHA" classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" trust-store="/opscenter/security/keystore/truststore_gf" cert-nickname="s1as"></ssl>
      </protocol>

      I notice the following in debugger:
      GlassfishSSLImpl#getServerSocketFactory() --> new GlassfishServerSocketFactory()
      and we have GlassfishServerSocketFactory#getKeyManagers as follows:

              if (sslUtils == null) {
                  initSSLUtils();
              }
              String keystoreFile = (String) attributes.get("keystore");
              if (logger.isLoggable(Level.FINE)) {
                  logger.log(Level.FINE, "Keystore file= {0}", keystoreFile);
              }
      
              String keystoreType = (String) attributes.get("keystoreType");
              if (logger.isLoggable(Level.FINE)) {
                  logger.log(Level.FINE, "Keystore type= {0}", keystoreType);
              }
              KeyManager[] kMgrs = sslUtils.getKeyManagers(algorithm);
              if (keyAlias != null && keyAlias.length() > 0 && kMgrs != null) {
                  for (int i = 0; i < kMgrs.length; i++) {
                      kMgrs[i] = new J2EEKeyManager((X509KeyManager) kMgrs[i], keyAlias);
                  }
              }
              return kMgrs;
          }
      

      (a) I notice that the keystoreFile are correctly pick up from protocol ssl element.
      (b) the keystoreFile above is computed but "not" used in the computation of key managers
      (c) The key managers are dervied from SSLUtils which is looked up from habitat.
      However, we have
      SSLUtils is scoped by Singleton.class
      (ii) inside SSLUtils, the key managers are computed from SecuritySupportImpl.java
      (iii) SecuritySupportImpl is also Singleton scoped
      also, #initJKS method only get keystores info from jvm options

        Activity

        Hide
        kumarjayanti added a comment -

        "" is not secure because in this case the default Grizzly SSLImplementation is used and it expects the keystore and truststore passwords to be supplied

        Either as additional attributes in the ssl element,
        OR
        as System properties javax.net.ssl.keyStorePassword and javax.net.ssl.trustStorePassword.

        The default impl as you know reads Keystore and TrustStore from the System properties javax.net.ssl.keyStore and javax.net.ssl.trustStore so there is no issue there.

        However you seem to have found an issue that GlassFish cannot be started if trustStore points to a different location other than domain config. This problem is independent of the Default SSL Implementation and i see that you have filed a different bug for that.

        Show
        kumarjayanti added a comment - "" is not secure because in this case the default Grizzly SSLImplementation is used and it expects the keystore and truststore passwords to be supplied Either as additional attributes in the ssl element, OR as System properties javax.net.ssl.keyStorePassword and javax.net.ssl.trustStorePassword. The default impl as you know reads Keystore and TrustStore from the System properties javax.net.ssl.keyStore and javax.net.ssl.trustStore so there is no issue there. However you seem to have found an issue that GlassFish cannot be started if trustStore points to a different location other than domain config. This problem is independent of the Default SSL Implementation and i see that you have filed a different bug for that.
        Hide
        Shing Wai Chan added a comment -

        Can you clarify why "" is "not" secure?
        If it is really not secure, then I think we should fix our default implementation to support the switching keystores as one don't want to compromise the security by using a two different keystores.

        Show
        Shing Wai Chan added a comment - Can you clarify why "" is "not" secure? If it is really not secure, then I think we should fix our default implementation to support the switching keystores as one don't want to compromise the security by using a two different keystores.
        Hide
        kumarjayanti added a comment -

        Shing Wai wrote :
        ------------
        Now we have the following questions.
        1) Now, by default, we use GlassfishSSLImpl. It seems that we should use "" here.
        "" means that we will use the default from Grizzly.
        Should we always use "" as a default?

        2) If we edit the ssl keystore and truststore from admin console, then the classname will be set to GlassfishSSLImpl. And one cannot set the classname to "" from admin console.
        ----------------

        Comment on #1 : So we cannot switch to "" as the default because we need to be secure by default.

        Comment on #2 : Agreed this is an issue and we need to fix this in the CLI command. when explicit keystore and truststore are specified then the command should remove the classname.

        Show
        kumarjayanti added a comment - Shing Wai wrote : ------------ Now we have the following questions. 1) Now, by default, we use GlassfishSSLImpl. It seems that we should use "" here. "" means that we will use the default from Grizzly. Should we always use "" as a default? 2) If we edit the ssl keystore and truststore from admin console, then the classname will be set to GlassfishSSLImpl. And one cannot set the classname to "" from admin console. ---------------- Comment on #1 : So we cannot switch to "" as the default because we need to be secure by default. Comment on #2 : Agreed this is an issue and we need to fix this in the CLI command. when explicit keystore and truststore are specified then the command should remove the classname.
        Hide
        Shing Wai Chan added a comment -

        Per discussion with Kumar, this bug is similar to http://java.net/jira/browse/GLASSFISH-15973.

        I have manually classname attribute in ssl protocol element.
        Then it works.

        Now we have the following questions.
        1) Now, by default, we use GlassfishSSLImpl. It seems that we should use "" here.
        "" means that we will use the default from Grizzly.
        Should we always use "" as a default?

        2) If we edit the ssl keystore and truststore from admin console, then the classname will be set to GlassfishSSLImpl. And one cannot set the classname to "" from admin console.

        Show
        Shing Wai Chan added a comment - Per discussion with Kumar, this bug is similar to http://java.net/jira/browse/GLASSFISH-15973 . I have manually classname attribute in ssl protocol element. Then it works. Now we have the following questions. 1) Now, by default, we use GlassfishSSLImpl. It seems that we should use "" here. "" means that we will use the default from Grizzly. Should we always use "" as a default? 2) If we edit the ssl keystore and truststore from admin console, then the classname will be set to GlassfishSSLImpl. And one cannot set the classname to "" from admin console.

          People

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

            Dates

            • Created:
              Updated: