= 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:
{{{#!sh
openssl genrsa -out my.key 2048
}}}

Then create the certificate from it:
{{{#!sh
openssl req -x509 -new -nodes -key my.key -sha256 -days 1024 -out my.pem
}}}
(without the prompts)
{{{#!sh
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):
{{{#!sh
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:
{{{#!sh
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:
{{{#!sh
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:

{{{#!sh
-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:

{{{#!sh
-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 [https://itnext.io/java-rmi-for-pentesters-structure-recon-and-communication-non-jmx-registries-a10d5c996a79 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.

[[Image(nmap-rmi.png)]]