Mirth Connect has many ways to manage SSL connections. This gist provides a primer on how to manage them. Edits, contributions, and corrections are appreciated!

Managing SSL Connections in MC.md

Mirth Connect is awesome! One common question on the forums and Slack is how to manage SSL connctions. These questions mainly focus on HTTPS but also include TCP connections.

The quick rundown is:

1. The built-in MC HTTP Sender connector will do HTTPS if:

• The endpoint has a certificate which is signed by a CA already present in the JVM truststore and has the right DN or SAN for the hostname. This is logically equivalent to the "green check" if you open the URL in a browser.
• The certificate has been added to the truststore for the JVM that MC is running under
• Changes to DNS or host files allow a hostname to match the DN or SAN already present in the cert (not reccomended)
• The connector may flag these connections with a warning or red x. Test the channel first as the validator makes assumptions about SSL that may not apply in this case.

2. The built-in MC HTTP Listener connector will not do SSL directly. A plugin or a proxy is necessary.

• Tony Germano has a plugin implemented for SSL listeners for HTTPS at https://github.com/tonygermano/connect-plugins
• Another open source SSL implementation is at https://github.com/tobchen/tc-ssl-plugin

4. SSL firewalls or stunnel can also proxy the SSL connections. MC connects to the unsecured side of the tunnel and the SSL layer is handled on the other side. Open source tools:

• stunnel https://www.stunnel.org/

• haproxy http://www.haproxy.org/

• nginx https://docs.nginx.com/

  An open-source tool that lets Mirth Connect manage stunnel has been published at https://github.com/pacmano1/mirthstunnel

5. Commercial solutions

• Mirth has a commercial SSL extension - https://www.nextgen.com/products-and-services/integration-engine
• Zen Healthcare IT has a an SSL extension with up-front pricing at - https://consultzen.com/zen-ssl-extension/
• Innovar has published an AWS instance with SSL support at - https://aws.amazon.com/marketplace/pp/prodview-rrvfqfm5vxbtk

6. Channel code - You can use tools like Apache HTTP Commons or OKHttp in MC and use that code to deal with SSL

The main consideration between these options are:

• Who is expected to manage the connections? Interface engineers benefit from options plugins that keep this inside MC. Network engineers and devops will tend to prefer proxies and tunnels that are closer to the infrastructure layer than the application layer.
• When will certs expire and what are the corporate policies about cert management? Most certificates are good for 1 to 3 years, that means that updates are required as the certificates expire. What option is easies for your organization to a) detect this expiration and b) update certificates BEFORE they expire as routine maintenance?
• What other software in your environment uses SSL and how is that managed?

Additional examples and references:

• A tutorial to communicate with DICOM over TLS, without using paid tools is at https://saga-it.com/blog/mirth-connect-dicom-over-tls/. This example also shows how to manage the Mirth truststore, it should work similarly for HTTP or TCP.
• An open-source tool that lets Mirth Connect manage stunnel has been published at https://github.com/pacmano1/mirthstunnel
• A limited open-source SSL plugin is at https://github.com/tonygermano/connect-plugins

Hello
thanks a lot for this valuable information
if we need more information about the above mention points can you please suggest references or more articles talked in depth
about each point.

I also notice that the following link https://kailo.tech/health-it/mirth-connect-add-ssl/ is not working

Regards,
Hisham Alrashdan

@jonbartels Thanks for this info!
This (and all the other stuff I'm finding) talks about encryption for HTTP connectors
Can you help with how to set up TLS for a TCP connector?

@wshallwshall - The Zen SSLEXT supports TCP with SSL if you just want to hit the easy button.

Otherwise the same general points apply - an endpoint presenting a fully signed certificate chain should "just work", using stunnel or nginx to manage SSL connections will also work.

Open source tools:

• stunnel https://www.stunnel.org/
• haproxy http://www.haproxy.org/
• nginx https://docs.nginx.com/

Be mindful that these tools may or may not be compliant with USA healthcare securtiry requirements as it pertains to encryption of data end to end.

Anything which does standard SSL/TLS should be acceptable under HIPAA/HITECH in the US and similar regulations elsewhere. All of the open source tools @pacmano1 mentions use OpenSSL under the hood, at least in their standard packaging.

I've had great success with stunnel but I'm in a *NIX environment where it is more natural than, say, Microsoft Windows. IMHO, haproxy and nginx are overkill for this application.

@ChristopherSchultz - I was referring to the occassional arguments with clients who do their own security assessments and say "we don't consider SSL termination without encryption from the offloader machine to the end machine to be fully compliant to USA healthcare security requirement".

Aha.

Whenever I'm using stunnel, it's terminating "real" network connections using TLS and proxying to (always!) localhost non-encrypted connections. Yes, it's possible to terminate TLS on one machine and proxy to another machine on the network, but that (for me) violates what is now called TNO ("Trust No One") / Zero-Trust architecture. We (at $work) have operated this way since the beginning using the policy of "no privileged network positions".

Non-encrypted connections to localhost ought to be okay for most network security folks.