Mutual TLS Connectivity

This page isn't strictly related to MadMartian? Mod but it is necessary for JMX over TLS which we use to monitor MadMartian? Mod remotely and securely.

Mutual Trust

Both the client (Java Mission Control) and the server (JMX) require three things:

• Self-signed certificate
• Private key
• Trust store

Self-signed certificates come with a private key (standard PKI), that's the infamous pair right there (you hare). The trust store is for storing the other side's public key.

Generate Self-Signed Certificate and Private Key Store

Before we get started it is imperative that the store passwords match the private key passwords, otherwise you'll get unrecoverable key errors when trying to handshake.

First step is to generate a private key:

openssl genrsa -out my.key 2048

Then create the certificate from it:

openssl req -x509 -new -nodes -key my.key -sha256 -days 1024 -out my.pem

(without the prompts)

openssl req -x509 -new -nodes -key my.key -sha256 -days 1024 -out my.pem -subj '/C=CA/ST=British Columbia/L=Vancouver/O=extollIT Enterprises/OU=Gauss Projects/CN=Minecraft JMX/emailAddress=support@extollit.com'

Now create a PKCS12 store from the PKI pair (private key + public cert):

openssl pkcs12 -export -name my-side -in my.pem -inkey my.key -out my.p12

Replace my-side with the side that the certificate belongs to ('server' if it will reside on the server and be trusted by the client and vice versa for the client)

Import the PKCS12 store into a local JKS:

keytool -importkeystore -destkeystore my.jks -srckeystore my.p12 -srcstoretype pkcs12 -alias my-side -deststoretype pkcs12

Trust The Other Side's Certificate

Once you have completed generating certificates for both sides you must now create the trust relationship between them:

Trust the other side's certificate:

keytool -import -alias other-side -file other.pem -keystore my.trust.jks

Java Mission Control

Settings for Java Mission Control are configured at $JAVA_HOME/bin/jmc.ini, add these configurations to setup the JMC client:

-Djavax.net.ssl.keyStore=<key-store-location>
-Djavax.net.ssl.trustStore=<trust-store-location>
-Djavax.net.ssl.keyStorePassword=< redacted >
-Djavax.net.ssl.trustStorePassword=< redacted >

If you're running into trouble then enable debug logging:

-Djavax.net.debug=ssl:handshake:verbose:keymanager:trustmanager 
-Djava.security.debug=access:stack

The JMC logs are generated at ~/.jmc/<version>/.metadata/.plugins/org.eclipse.ui.workbench/log

Attack Vectors

Exposing the JMI registry can be easily achieved with the help of a handy nmap script, fortunately the real vulnerable JMI endpoint is protected by TLS. I ran the script described in ​this article on pentesting RMI and all it revealed is that there is an encrypted RMI endpoint on the TCP port next door. With mutual X509 PKI authentication the risk is significantly mitigated AFAIK.