TLS Manager Plugin

Download the ZIP file from the GitHub releases page and import it using OIE's standard plugin import mechanism. The plugin is signed by NovaMap Health using a code signing certificate issued by a public CA, so you can verify its authenticity. Java 17 or later is required for both OIE and the Launcher.

For a detailed walkthrough, refer to the user guide (PDF).

The plugin adds TLS capabilities to the following connector types:

• HTTP Senders and Listeners
• Web Service Senders and Listeners
• TCP Senders and Listeners (operable in client or server mode)

Existing channels using these connectors continue to function after installation — no migration or reconfiguration is required.

Once the plugin is installed, the web-based Certificate Manager is available at [base URL]/tls-manager — most commonly https://localhost:8443/tls-manager. You must authenticate with your existing OIE credentials before accessing it.

By default, all certificates, key pairs, aliases, and TLS configuration settings are stored in the OIE database (mirthdb). This means no manual keystore file management is required. File-based keystore storage is also supported and can be enabled via environment variables — see the user guide for details.

Mutual TLS (mTLS) requires both the client and the server to present certificates during the TLS handshake. This ensures both parties are authenticated, not just the server.

The plugin supports mTLS on all supported connector types. It is configured per-channel via the extended connector properties that the plugin adds to the standard OIE connector UI.

Yes. Each connector lets you select the permitted TLS versions (for example, TLS 1.2 only, or TLS 1.2 and TLS 1.3) and an explicit whitelist of permitted cipher suites. This gives you precise control to meet your security policy or compliance requirements without relying on JVM defaults.

The plugin supports both CRL (Certificate Revocation List) and OCSP (Online Certificate Status Protocol) checking. Both can be enabled independently, and each has a configurable strict-fail mode — when enabled, the connection will be rejected if the revocation status cannot be determined (for example, if the CRL endpoint is unreachable).

No. Backward compatibility has been thoroughly tested. The plugin replaces the standard HTTP, Web Service, and TCP connectors transparently, and channels that do not have TLS properties configured continue to operate exactly as before. Load testing was also performed to confirm there is no meaningful increase in latency or impact on multi-threading.

Subject DN validation allows you to assert that the Distinguished Name (DN) in a peer's certificate matches an expected value. This is useful when multiple clients share the same CA but should have different access rights.

Hostname validation ensures that the hostname in the peer's certificate matches the hostname of the connection endpoint, providing protection against certificate reuse across different hosts.

The TLS Manager will work with any version of Mirth Connect™ or fork of Mirth Connect™ such as Bridgelink that implements the Mirth Connect™ 4.5.2 API.

Yes. By setting the OIE_TLS_PLUGIN_PERSISTENCE_BACKEND environment variable to filesystem, the TLS Manager will use file-based keystores. See the user guide for more details.

Use the GitHub Issues page for bug reports and feature requests. For support on NovaMap-hosted OIE instances, contact support@novamap.health.