glassfish
  1. glassfish
  2. GLASSFISH-20671

enable-/disable-secure-admin should set/clear SSL on JMX also

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0, 4.1
    • Fix Version/s: 4.1
    • Component/s: amx
    • Labels:
      None

      Description

      Currently, the enable- and disable-secure-admin commands affect the admin listener for the DAS but they do not change the SSL settings for JMX settings.

      Ideally, enable- and disable-secure-admin should affect both.

        Activity

        Hide
        Tim Quinn added a comment -

        There are various blogs that show how to configure manually the JMX connection for SSL. These steps should be automated as part of the secure admin commands, not only for the convenience of users (to avoid the manual configuration steps) but also so the commands perform a "complete lock-down" (or undo a complete lock-down) as far as admin security is concerned.

        Show
        Tim Quinn added a comment - There are various blogs that show how to configure manually the JMX connection for SSL. These steps should be automated as part of the secure admin commands, not only for the convenience of users (to avoid the manual configuration steps) but also so the commands perform a "complete lock-down" (or undo a complete lock-down) as far as admin security is concerned.
        Hide
        Tim Quinn added a comment - - edited

        One minor complication with a fix for this is that there is a bug in jconsole which causes connections to SSL-protected JMX endpoints via

        service:jmx:rmi://hostname:8686/jndi/rmi://hostname:8686/jmxrmi

        to fail when SSL is enabled. (I have written to the serviceability team who owns jconsole but have not heard back yet about whether they have plans to address this.)

        Note that jconsole will connect to the secured DAS if you specify

        hostname:8686

        (instead of using the full service:... string).

        Custom clients which include code like this (particularly the second "env.put" invocation)

        env.put(JMXConnector.CREDENTIALS, credentials);
        env.put("com.sun.jndi.rmi.factory.socket", new SslRMIClientSocketFactory());
        final JMXServiceURL jmxURL = new JMXServiceURL("service:jmx:rmi://" + host + ":8686/jndi/rmi://" + host + ":8686/jmxrmi");
        final JMXConnector jmxConnector = JMXConnectorFactory.connect(jmxURL, env);
        

        will work.

        VisualVM is able to connect to a secured DAS successfully. Although VisualVM out-of-the-box does not expose the MBean in the targeted JVM, users can add the MBean plug-in to VisualVM (described and downloadable from https://visualvm.java.net/mbeans_tab.html).

        In any scenario that works, users first need to run any asadmin command that contacts the DAS which now has secure admin enabled. This caches the DAS cert in the local GlassFish truststore (in the ~/.gfclient/truststore file). Then uses can specify the truststore location and password using system properties on the command:

        jvisualvm -J-Djavax.net.ssl.trustStore=/Users/your-username/.gfclient/truststore -J-Djavax.net.ssl.trustStorePassword=changeit 
        

        and create a connection to the GlassFish JVM using the JMX connection and the conventional connection string, thus gaining access to the MBeans in the JVM.

        Show
        Tim Quinn added a comment - - edited One minor complication with a fix for this is that there is a bug in jconsole which causes connections to SSL-protected JMX endpoints via service:jmx:rmi://hostname:8686/jndi/rmi://hostname:8686/jmxrmi to fail when SSL is enabled. (I have written to the serviceability team who owns jconsole but have not heard back yet about whether they have plans to address this.) Note that jconsole will connect to the secured DAS if you specify hostname:8686 (instead of using the full service:... string). Custom clients which include code like this (particularly the second "env.put" invocation) env.put(JMXConnector.CREDENTIALS, credentials); env.put( "com.sun.jndi.rmi.factory.socket" , new SslRMIClientSocketFactory()); final JMXServiceURL jmxURL = new JMXServiceURL( "service:jmx:rmi: //" + host + ":8686/jndi/rmi://" + host + ":8686/jmxrmi" ); final JMXConnector jmxConnector = JMXConnectorFactory.connect(jmxURL, env); will work. VisualVM is able to connect to a secured DAS successfully. Although VisualVM out-of-the-box does not expose the MBean in the targeted JVM, users can add the MBean plug-in to VisualVM (described and downloadable from https://visualvm.java.net/mbeans_tab.html ). In any scenario that works, users first need to run any asadmin command that contacts the DAS which now has secure admin enabled. This caches the DAS cert in the local GlassFish truststore (in the ~/.gfclient/truststore file). Then uses can specify the truststore location and password using system properties on the command: jvisualvm -J-Djavax.net.ssl.trustStore=/Users/your-username/.gfclient/truststore -J-Djavax.net.ssl.trustStorePassword=changeit and create a connection to the GlassFish JVM using the JMX connection and the conventional connection string, thus gaining access to the MBeans in the JVM.
        Hide
        Tim Quinn added a comment - - edited

        I have opened an issue against jconsole in the Java SE bug database at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020207 "jconsole fails connecting over SSL using service:jmx:rmi://...jndi..."

        Show
        Tim Quinn added a comment - - edited I have opened an issue against jconsole in the Java SE bug database at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020207 "jconsole fails connecting over SSL using service:jmx:rmi://...jndi..."
        Hide
        Tim Quinn added a comment -

        Fix checked in.

        Project: glassfish
        Repository: svn
        Revision: 62357
        Author: tjquinn
        Date: 2013-07-16 21:43:35 UTC
        Link:

        Log Message:
        ------------
        Fix for GLASSFISH-20671

        The enable- and disable-secure-admin commands now automatically change the JMX connector security settings (as well as the DAS admin listener settings which they already did).

        Tests: QL, manual tests of using jvisualvm with GlassFish

        Revisions:
        ----------
        62357

        Modified Paths:
        ---------------
        trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/admin/cli/SecureAdminCommand.java

        Show
        Tim Quinn added a comment - Fix checked in. Project: glassfish Repository: svn Revision: 62357 Author: tjquinn Date: 2013-07-16 21:43:35 UTC Link: Log Message: ------------ Fix for GLASSFISH-20671 The enable- and disable-secure-admin commands now automatically change the JMX connector security settings (as well as the DAS admin listener settings which they already did). Tests: QL, manual tests of using jvisualvm with GlassFish Revisions: ---------- 62357 Modified Paths: --------------- trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/admin/cli/SecureAdminCommand.java
        Hide
        Tim Quinn added a comment -

        There is a config listener that processed config changes to Ssl config beans which are used in the fix for this issue. That listener assumed that the parent of every Ssl config bean reported via the config change mechanism was a Protocol. Although that happened to be true prior to this fix, this fix caused JmxConnector to also be a parent of changed Ssl config beans.

        I checked in a change to that class to differentiate between those cases, but that logic was incorrect and it triggered an error in a web devtest.

        I've checked in a subsequent fix that differentiates correctly and fixed the failing web detests.

        Project: glassfish
        Repository: svn
        Revision: 62434
        Author: tjquinn
        Date: 2013-07-31 14:10:46 UTC
        Link:

        Log Message:
        ------------
        Further refinement to the fix for GLASSFISH-20671

        The <ssl> element can be a child either of <protocol> or <jmx-connector>. The config listener did not distinguish, always assuming the parent of the <ssl> element was a <protocol> which caused problems. The earlier fix for GLASSFISH-20671 used an incorrect test to detect if the parent was in fact a <protocol>.

        This change repairs that problem.

        Tests: QL, RQ, failing web devtests

        Revisions:
        ----------
        62434

        Modified Paths:
        ---------------
        trunk/main/nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/services/impl/DynamicConfigListener.java

        Show
        Tim Quinn added a comment - There is a config listener that processed config changes to Ssl config beans which are used in the fix for this issue. That listener assumed that the parent of every Ssl config bean reported via the config change mechanism was a Protocol. Although that happened to be true prior to this fix, this fix caused JmxConnector to also be a parent of changed Ssl config beans. I checked in a change to that class to differentiate between those cases, but that logic was incorrect and it triggered an error in a web devtest. I've checked in a subsequent fix that differentiates correctly and fixed the failing web detests. Project: glassfish Repository: svn Revision: 62434 Author: tjquinn Date: 2013-07-31 14:10:46 UTC Link: Log Message: ------------ Further refinement to the fix for GLASSFISH-20671 The <ssl> element can be a child either of <protocol> or <jmx-connector>. The config listener did not distinguish, always assuming the parent of the <ssl> element was a <protocol> which caused problems. The earlier fix for GLASSFISH-20671 used an incorrect test to detect if the parent was in fact a <protocol>. This change repairs that problem. Tests: QL, RQ, failing web devtests Revisions: ---------- 62434 Modified Paths: --------------- trunk/main/nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/services/impl/DynamicConfigListener.java

          People

          • Assignee:
            Tim Quinn
            Reporter:
            Tim Quinn
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: