Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] configuring JMX interface to use SSL

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.: -> jetty.jmxremote.rmiport -> jmx.remote.x.password.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.

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
  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:
  2017-02-07 18:05:59.279:INFO:oejs.ServerConnector:main: Started
  ServerConnector@67b64c45{SSL,[ssl, http/1.1]}{}
  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.
  issuer=/C=Unknown/ST=Unknown/L=Unknown/O=Mort Bay Consulting Pty.

But, the JMX interface does not:

  # openssl s_client -connect localhost:1099 < /dev/null
  140439511435080:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
  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:

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 / joakim@xxxxxxxxxxx

Brian Reichert				<reichert@xxxxxxxxxxx>
BSD admin/developer at large	

Back to the top