glassfish
  1. glassfish
  2. GLASSFISH-15973

keystore / trust-store per ssl listener not working

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1_b41
    • Fix Version/s: None
    • Component/s: web_container
    • Labels:
      None

      Description

      I tried to configure keystore/truststore per ssl listener as described in GLASSFISH-657

      <protocol security-enabled="true" name="http-listener-2">
      <http default-virtual-server="server">
      <file-cache></file-cache>
      </http>
      <ssl key-store="mystore.jks" ssl3-enabled="false" classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" trust-store="mytrust.jks" cert-nickname="mynick"></ssl>
      </protocol>

      tested with absolute path and file name only, both result in the following exception.
      I checked that files and nickname exists. Am I missing something else here?

      GRIZZLY0007: SSL support could not be configured!
      java.io.IOException: SSL configuration is invalid due to No available certificate or key corresponds to the SSL cipher suites which are enabled.
      at com.sun.grizzly.util.net.jsse.JSSE14SocketFactory.checkConfig(JSSE14SocketFactory.java:455)
      at com.sun.grizzly.util.net.jsse.JSSE14SocketFactory.init(JSSE14SocketFactory.java:183)
      at com.sun.grizzly.config.SSLConfigHolder.initializeSSL(SSLConfigHolder.java:361)
      at com.sun.grizzly.config.SSLConfigHolder.configureSSL(SSLConfigHolder.java:237)
      at com.sun.grizzly.config.GrizzlyEmbeddedHttps$LazySSLInitializationFilter.execute(GrizzlyEmbeddedHttps.java:202)
      at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
      at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
      at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
      at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
      at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
      at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
      at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
      at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
      at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
      at java.lang.Thread.run(Thread.java:662)
      Caused by: javax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled.
      at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:310)
      at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:255)
      at com.sun.grizzly.util.net.jsse.JSSE14SocketFactory.checkConfig(JSSE14SocketFactory.java:451)
      ... 14 more

        Activity

        Hide
        Ryan Lubke added a comment -

        Please refer to: http://download.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#Troubleshooting

        There is a section specifically for the exception you're receiving. Please review the suggestions and take corrective action.

        If there are still issues, after doing so, please follow up here.

        Show
        Ryan Lubke added a comment - Please refer to: http://download.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#Troubleshooting There is a section specifically for the exception you're receiving. Please review the suggestions and take corrective action. If there are still issues, after doing so, please follow up here.
        Hide
        schaarsc added a comment -

        according to the link you provided, the keystore/truststore might be broken, but I'm using this keystore/truststore with GFv2 without problems.

        if I configure this files with JVM options -Djavax.net.ssl... I get a different stacktrace, but still no hint what the problem might be

        GRIZZLY0007: SSL support could not be configured!
        java.io.IOException: injection failed on com.sun.enterprise.security.ssl.SSLUtils.secSupp with class com.sun.enterprise.server.pluggable.SecuritySupport
        at com.sun.grizzly.util.net.jsse.JSSE14SocketFactory.init(JSSE14SocketFactory.java:188)
        at com.sun.grizzly.config.SSLConfigHolder.initializeSSL(SSLConfigHolder.java:361)
        at com.sun.grizzly.config.SSLConfigHolder.configureSSL(SSLConfigHolder.java:237)
        at com.sun.grizzly.config.GrizzlyEmbeddedHttps$LazySSLInitializationFilter.execute(GrizzlyEmbeddedHttps.java:202)
        at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
        at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
        at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
        at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
        at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
        at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
        at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
        at java.lang.Thread.run(Thread.java:662)

        Show
        schaarsc added a comment - according to the link you provided, the keystore/truststore might be broken, but I'm using this keystore/truststore with GFv2 without problems. if I configure this files with JVM options -Djavax.net.ssl... I get a different stacktrace, but still no hint what the problem might be GRIZZLY0007: SSL support could not be configured! java.io.IOException: injection failed on com.sun.enterprise.security.ssl.SSLUtils.secSupp with class com.sun.enterprise.server.pluggable.SecuritySupport at com.sun.grizzly.util.net.jsse.JSSE14SocketFactory.init(JSSE14SocketFactory.java:188) at com.sun.grizzly.config.SSLConfigHolder.initializeSSL(SSLConfigHolder.java:361) at com.sun.grizzly.config.SSLConfigHolder.configureSSL(SSLConfigHolder.java:237) at com.sun.grizzly.config.GrizzlyEmbeddedHttps$LazySSLInitializationFilter.execute(GrizzlyEmbeddedHttps.java:202) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:662)
        Hide
        schaarsc added a comment -

        I managed to start the DAS with my certificates by adding JVM options -Djavax.net.ssl...
        then I stopped the DAS and changed domain.xml
        from
        <ssl client-auth="want" ssl3-enabled="false" classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" cert-nickname="s1as"></ssl>
        to
        <ssl client-auth="want" ssl3-enabled="false" keystore="$

        {com.sun.aas.instanceRoot}/config/keystore.jks" classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" trust-store="${com.sun.aas.instanceRoot}

        /config/cacerts.jks" cert-nickname="s1as"></ssl>
        after restart DAS is still using my own certificate, not the self-signed cert generated during create-domain

        then I stopped the DAS again and changed the nickname
        from s1as
        to glassfish-instance
        now I get this exception
        GRIZZLY0007: SSL support could not be configured!
        java.io.IOException: SSL configuration is invalid due to No available certificate or key corresponds to the SSL cipher suites which are enabled.
        at com.sun.grizzly.util.net.jsse.JSSE14SocketFactory.checkConfig(JSSE14SocketFactory.java:455)
        at com.sun.grizzly.util.net.jsse.JSSE14SocketFactory.init(JSSE14SocketFactory.java:183)
        at com.sun.grizzly.config.SSLConfigHolder.initializeSSL(SSLConfigHolder.java:361)
        at com.sun.grizzly.config.SSLConfigHolder.configureSSL(SSLConfigHolder.java:237)
        at com.sun.grizzly.config.GrizzlyEmbeddedHttps$LazySSLInitializationFilter.execute(GrizzlyEmbeddedHttps.java:202)
        at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
        at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
        at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
        at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
        at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
        at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
        at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
        at java.lang.Thread.run(Thread.java:662)
        Caused by: javax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled.
        at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:310)
        at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:255)
        at com.sun.grizzly.util.net.jsse.JSSE14SocketFactory.checkConfig(JSSE14SocketFactory.java:451)
        ... 14 more

        Then I removed the -Djavax.net.ssl options and in the server.log I found this
        FINE|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=17;_ThreadName=Thread-1;ClassName=com.sun.enterprise.security.ssl.GlassfishServerSocketFactory;MethodName=getKeyManagers;|Keystore file= null|#]

        Is there something wrong with my domain.xml? Why is keystore file = null? shouldn't grizzly use the keystore defined in <ssl>-element?

        Show
        schaarsc added a comment - I managed to start the DAS with my certificates by adding JVM options -Djavax.net.ssl... then I stopped the DAS and changed domain.xml from <ssl client-auth="want" ssl3-enabled="false" classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" cert-nickname="s1as"></ssl> to <ssl client-auth="want" ssl3-enabled="false" keystore="$ {com.sun.aas.instanceRoot}/config/keystore.jks" classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" trust-store="${com.sun.aas.instanceRoot} /config/cacerts.jks" cert-nickname="s1as"></ssl> after restart DAS is still using my own certificate, not the self-signed cert generated during create-domain then I stopped the DAS again and changed the nickname from s1as to glassfish-instance now I get this exception GRIZZLY0007: SSL support could not be configured! java.io.IOException: SSL configuration is invalid due to No available certificate or key corresponds to the SSL cipher suites which are enabled. at com.sun.grizzly.util.net.jsse.JSSE14SocketFactory.checkConfig(JSSE14SocketFactory.java:455) at com.sun.grizzly.util.net.jsse.JSSE14SocketFactory.init(JSSE14SocketFactory.java:183) at com.sun.grizzly.config.SSLConfigHolder.initializeSSL(SSLConfigHolder.java:361) at com.sun.grizzly.config.SSLConfigHolder.configureSSL(SSLConfigHolder.java:237) at com.sun.grizzly.config.GrizzlyEmbeddedHttps$LazySSLInitializationFilter.execute(GrizzlyEmbeddedHttps.java:202) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:662) Caused by: javax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled. at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:310) at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:255) at com.sun.grizzly.util.net.jsse.JSSE14SocketFactory.checkConfig(JSSE14SocketFactory.java:451) ... 14 more Then I removed the -Djavax.net.ssl options and in the server.log I found this FINE|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=17;_ThreadName=Thread-1;ClassName=com.sun.enterprise.security.ssl.GlassfishServerSocketFactory;MethodName=getKeyManagers;|Keystore file= null|#] Is there something wrong with my domain.xml? Why is keystore file = null? shouldn't grizzly use the keystore defined in <ssl>-element?
        Hide
        Ryan Lubke added a comment -

        After discussion with Alexey, we feel this may be a security issue vs a Grizzly issue as the SocketFactory is provided by GlassFish. Asking the Security team to review.

        Show
        Ryan Lubke added a comment - After discussion with Alexey, we feel this may be a security issue vs a Grizzly issue as the SocketFactory is provided by GlassFish. Asking the Security team to review.
        Hide
        kumarjayanti added a comment -

        The idea of attribute classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" is to override the default Grizzly SSLImplementation with a different one. So when this attribute is not present then Grizzly would fall back to using its default implementation.

        If you observe (and look at what you described above) this particular GlassfishSSLImpl tries to use what was set in javax.net.ssl.* properties and not the ones defined in keystore attribute of the <ssl> element. The Grizzly SSL Implementation would read the kesystore attribute passed to the <ssl> element. And if the password for the keystore is different from "changeit" then you will need to pass that as well in the ssl element.

        So what does the GlassFishSSLImpl achieve ?. It coordinates with the admin runtime to make use of the GF master-password as the keystore password in such a way that you do not need to explicitly specify any passwords in clear-text inside the grizzly ssl element.

        So the solution for you is just remove the classname attribute when you are specifying the keystore attribute.

        I am closing the issue.

        Show
        kumarjayanti added a comment - The idea of attribute classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" is to override the default Grizzly SSLImplementation with a different one. So when this attribute is not present then Grizzly would fall back to using its default implementation. If you observe (and look at what you described above) this particular GlassfishSSLImpl tries to use what was set in javax.net.ssl.* properties and not the ones defined in keystore attribute of the <ssl> element. The Grizzly SSL Implementation would read the kesystore attribute passed to the <ssl> element. And if the password for the keystore is different from "changeit" then you will need to pass that as well in the ssl element. So what does the GlassFishSSLImpl achieve ?. It coordinates with the admin runtime to make use of the GF master-password as the keystore password in such a way that you do not need to explicitly specify any passwords in clear-text inside the grizzly ssl element. So the solution for you is just remove the classname attribute when you are specifying the keystore attribute. I am closing the issue.
        Hide
        schaarsc added a comment -

        I'll check this suggestion tomorrow, don't have access right now.

        Before you close this issue please consider to make an improvement out of this.
        admin gui does provide fields to set keystore and trust-store, as far as I know, there is no field to change the classname for Impl-class. Furthermore, I don't think that the burden on choosing the right Impl for ssl listeners should be placed on the user. How should the user find out about the possible Impls and what they do?
        Suggestion: enhance GlassfishSSLImpl to use ssl attributes and fallback to javax.net.ssl if not set. admin gui stays unchanged.

        Show
        schaarsc added a comment - I'll check this suggestion tomorrow, don't have access right now. Before you close this issue please consider to make an improvement out of this. admin gui does provide fields to set keystore and trust-store, as far as I know, there is no field to change the classname for Impl-class. Furthermore, I don't think that the burden on choosing the right Impl for ssl listeners should be placed on the user. How should the user find out about the possible Impls and what they do? Suggestion: enhance GlassfishSSLImpl to use ssl attributes and fallback to javax.net.ssl if not set. admin gui stays unchanged.
        Hide
        kumarjayanti added a comment -

        Fixed.

        Show
        kumarjayanti added a comment - Fixed.
        Hide
        kumarjayanti added a comment -

        ------
        admin gui does provide fields to set keystore and trust-store, as far as I know, there is no field to change the classname for Impl-class.
        ------

        Yes you can file a bug on admin-gui for this.

        -------
        enhance GlassfishSSLImpl to use ssl attributes and fallback to javax.net.ssl if not set. admin gui stays unchanged.
        -------

        Actually the javax.net.ssl props are always set unless someone deletes them explicitly. And we do not advise deleting these properties.

        I guess the SSL configuration support is really a feature of Grizzly which gets exposed within GlassFish as well, but probably is more useful in other environments that use Grizzly than in GlassFish (i mean the full blown capabilities of the configuration). GlassFish only makes use of a subset of the configuration. The recommended way to change the GlassFish Keystore to something other than default is to set the javax.net.ssl.* properties.

        Also note that in a V3.1 cluster if you set your keystores to something outside the DAS config dir then you will have to manually take care of the synchronization of those stores across the cluster instances.

        Show
        kumarjayanti added a comment - ------ admin gui does provide fields to set keystore and trust-store, as far as I know, there is no field to change the classname for Impl-class. ------ Yes you can file a bug on admin-gui for this. ------- enhance GlassfishSSLImpl to use ssl attributes and fallback to javax.net.ssl if not set. admin gui stays unchanged. ------- Actually the javax.net.ssl props are always set unless someone deletes them explicitly. And we do not advise deleting these properties. I guess the SSL configuration support is really a feature of Grizzly which gets exposed within GlassFish as well, but probably is more useful in other environments that use Grizzly than in GlassFish (i mean the full blown capabilities of the configuration). GlassFish only makes use of a subset of the configuration. The recommended way to change the GlassFish Keystore to something other than default is to set the javax.net.ssl.* properties. Also note that in a V3.1 cluster if you set your keystores to something outside the DAS config dir then you will have to manually take care of the synchronization of those stores across the cluster instances.

          People

          • Assignee:
            kumarjayanti
            Reporter:
            schaarsc
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: