On Tue, Feb 07, 2017 at 09:10:37AM -0700, Joakim Erdfelt wrote: > Setting up the remote JMX port for SSL/TLS would be entirely within the > scope of the JVM options. > > Jetty is not involved in the JMX service, it merely exposes components to > the JMX layer.
But, jetty renames some of the properties, e.g.: com.sun.management.jmxremote.port -> jetty.jmxremote.rmiport com.sun.management.jmxremote.password.file -> jmx.remote.x.password.file com.sun.management.jmxremote.access.file -> jmx.remote.x.access.file > The rest is handled by the JVM. > > The instructions you have linked to are the only ones I'm aware of for > setting up the SSL certificates for JMX. > It also states that SSL/TLS is the default behavior for the JMX remote > agent. > > http://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html#gdemv Heck, let's ignore my config, and go right to stock jetty code, firing up JMX remote, and SSL: # cd /usr/jetty-distribution/demo-base # java -jar ../start.jar --module=jmx,jmx-remote,ssl 2017-02-07 17:44:21.783:INFO::main: Logging initialized @373ms 2017-02-07 17:44:23.199:WARN::main: demo test-realm is deployed. DO NOT USE IN PRODUCTION! 2017-02-07 17:44:23.201:INFO:oejs.Server:main: jetty-9.3.8.v20160314 2017-02-07 17:44:23.357:INFO:oejj.ConnectorServer:main: JMX Remote URL: service:jmx:rmi://localhost:1099/jndi/rmi://test-02.example.com:1099/jmxrmi ... 2017-02-07 18:05:59.279:INFO:oejs.ServerConnector:main: Started ServerConnector@67b64c45{SSL,[ssl, http/1.1]}{0.0.0.0:8443} 2017-02-07 18:05:59.280:INFO:oejs.Server:main: Started @3939ms So, I can see that the web app on port 8443 is on an SSL interface: # openssl s_client -connect localhost:8443 < /dev/null ...subject=/C=Unknown/ST=Unknown/L=Unknown/O=Mort Bay Consulting Pty. Ltd./OU=Jetty/CN=jetty.eclipse.org issuer=/C=Unknown/ST=Unknown/L=Unknown/O=Mort Bay Consulting Pty. Ltd./OU=Jetty/CN=jetty.eclipse.org ... But, the JMX interface does not: # openssl s_client -connect localhost:1099 < /dev/null CONNECTED(00000003) 140439511435080:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:184: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 247 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- According to Oracle, this should be protected with SSL by default. Authentication is enabled by default (and I can get that configured/working), but setting: -Dcom.sun.management.jmxremote.authenticate=false doesn't suppress the demand for credentials. So, it _seems_ to me that jetty, somehow, subverts how some of these properties are processed by the JVM. > Joakim Erdfelt / [email protected] -- Brian Reichert <[email protected]> BSD admin/developer at large _______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
