Claridex Certificate Manager — Windows install & admin guide

The native Windows standalone. It installs as two Windows services plus a bundled JRE, OpenSSL, and stunnel; you manage it in a browser at http://localhost:8800/.

This guide covers the Windows .exe installer. Single sign-on (Google / Microsoft Entra) is set up in §15.2, and Open Integration Engine (OIE) is supported everywhere Mirth Connect is.

Download the latest signed installer at https://claridex.co/download. Questions or a problem? Email support@claridex.co.

1. What it does

A single dashboard for the SSL/TLS certificates of your Mirth Connect / Open Integration Engine (OIE) server:

• Certificate overview — the Servers tab shows your server's health and soonest-expiring certificate, with generate / renew / import / CSR straight into the server's keystore (uses the bundled Java keytool + OpenSSL).
• Per-connector TLS — add TLS (and mutual TLS) to Mirth connectors that can't do it natively (MLLP/TCP, HTTP listeners), via a managed stunnel proxy — no Mirth plugin, any Mirth/OIE version. Test a connection before you commit to it, see at a glance whether each one is up, renew or replace its certificate, and export a certificate to send to a trading partner.
• Expiry notifications — email / Slack / webhook alerts before your certificates expire.
• Offline licensing — license keys verified locally, no internet needed.

Deployment model — one Claridex per Mirth server. Install Claridex on the same host as the Mirth server it secures, and manage exactly one Mirth server per install. This is required, not just recommended: the per-connector TLS proxy forwards a plaintext leg to Mirth's own listener, which is only safe when that hop stays on the local host (loopback). It's also how licensing works — one license key per install. To secure more than one Mirth server, run a separate Claridex install (with its own key) alongside each one. The app enforces this: once a server is added, "Add a server" is disabled.

It's self-hosted: it reads/writes TLS private keys and talks to the Mirth admin API, so it runs entirely inside your network.

2. System requirements

• 64-bit Windows 10 / 11 / Server 2016+.
• Local administrator rights (the installer registers Windows services; it opens firewall ports later, only when you enable per-connector TLS).
• Nothing else — Node.js, a Java runtime (keytool), OpenSSL, stunnel, and NSSM are all bundled in the installer.
• Network/filesystem access to the Mirth/OIE install(s) you want to manage.

3. Install

1. Download ClaridexCertificateManager-<version>-setup.exe from https://claridex.co/download.
2. If Windows flagged the download, right-click it -> Properties -> check Unblock -> OK.
3. Run it as administrator and approve the UAC prompt. The installer is code-signed, so UAC should name the verified publisher Claridex LLC — if it says Unknown publisher instead, stop and re-download; the file you have is not the one we published.
4. Accept the License Agreement (EULA).
5. On the Administrator account page, set a password for the built-in Administrator login. It must be at least 12 characters and include an uppercase letter, a lowercase letter, a number, and a symbol; enter it twice to confirm. (A password is only auto-generated on a silent install — below.)
6. On the Network port page, keep the default 8800 or enter another port for the app to listen on (it's served at http://localhost:<port>/, loopback only). You can change this later — see §12.
7. Finish. The installer registers and starts the services. The final page shows the URL — sign in as Administrator with the password you set. Only a scrypt hash of it is stored (admin-password.hash); the plaintext is never written to disk.

Silent / scripted install (GPO, mass deploy):

ClaridexCertificateManager-<version>-setup.exe /VERYSILENT /SUPPRESSMSGBOXES /NORESTART

A silent install generates a random admin password, but it is not recoverable (only its scrypt hash is stored). For unattended deployments set your own credential afterward — see §12 (ADMIN_PASSWORD_HASH) — or re-run the installer interactively and set one.

What gets installed

• App -> C:\Program Files\ClaridexCertificateManager\app, run by bundled node.exe as the ClaridexCertificateManager service on http://localhost:8800/ (localhost only).
• stunnel supervisor -> the ClaridexCertificateManagerStunnel service.
• Data -> C:\ProgramData\ClaridexCertificateManager\ (config.json, license.key, auth-secret, admin-password.hash, stunnel runtime, logs). Survives upgrades; not removed on uninstall.
• Both services are set to start automatically at boot.

4. First sign-in

1. Open http://localhost:8800/ (a Start-Menu shortcut is provided).
2. Sign in as Administrator with the password from install.
3. You land on the Connectors page (empty until you add a server). The Servers tab gives you the cross-server certificate overview.

The whole app is gated behind login (an AUTH_SECRET is generated at install). To change the admin password later, use Users -> Change admin password, or re-run the installer and set a new one (it overrides the stored hash). Advanced: set ADMIN_PASSWORD_HASH (a scrypt hash) in the service env — plain ADMIN_PASSWORD is only honored when no hash is set (see §12). SSO (Google/Entra) is optional — see §15.2.

5. Activate your license

Changes are blocked until a license is active (viewing always works).

1. Open License (under the Settings menu).
2. Paste your key and activate. It's verified locally — no internet required.
3. Status shows: customer, plan, and days remaining.

One key per install. Each Claridex install is licensed by a single key and manages one Mirth server (§1). If you purchased more than one server, you receive one key per server — install Claridex alongside each Mirth and paste that server's key. Don't reuse a key across installs; each key is for one Mirth instance (see the license agreement).

Lifecycle: active -> on expiry a grace window (default 14 days, full function + a banner) -> read-only (viewing + expiry alerts keep working, but changes are blocked) until you paste a new key. Live traffic is never interrupted.

Trial keys: a trial key (plan: trial) behaves like a paid one but for a fixed evaluation period (typically 30 days) with no grace window. While active the status reads "Trial — N day(s) left"; at expiry the app goes read-only with "Your trial has ended." To convert, just paste a paid key over it — it takes effect immediately, even after the trial has expired. Existing certificates and TLS proxies keep running throughout.

6. Add a server

Everything starts on the Connectors page: it prompts you to add your Mirth server. Claridex manages one Mirth server per install (§1), so once you've added it the Add a server control is disabled. It's a short guided flow:

1. Locate — enter the path to the Mirth/OIE install (or its conf/mirth.properties directly), e.g. C:\Program Files\Mirth Connect, and click Discover keystores. It reads mirth.properties server-side (so store passwords never leave the host), finds the keystore/truststore, and trial-reads them to confirm they're readable (a built-in reader for JKS stores; the bundled keytool for PKCS12 / JCEKS).
2. Name — give the server a name (e.g. "Prod East") and click Add server.
3. Connect — optionally connect its Mirth admin API now so its connectors appear immediately (see §8). You can skip this and do it later.

Your server then appears on the Servers tab (§7) and on the Connectors page. If you ever need to point Claridex at a different Mirth install, use Remove server first (its keystores on disk are untouched), then add the new one.

Confining discovery (recommended): by default an authed admin can point discovery at any host path. To limit it to one folder tree, set MIRTH_DISCOVERY_BASE (see §12).

7. Servers: your certificate overview

The Servers tab (top nav) is where you manage your Mirth server's certificates:

• It shows the server's health, soonest-expiring cert, and a valid / expiring / expired count.
• Click the server (or Open) to see its keystore(s) and certificate entries (subject, issuer, expiry, key type). A keystore holds the server's own certificates (its identities); a truststore, if your Mirth has one, holds certificates it trusts. Many Mirth installs keep everything in one keystore and have no separate truststore — that's fine.
• Every change backs up the store first (a timestamped .bak).

7.1 Which certificate action do I use?

On a keystore, click + Add to open the Server certificate actions. Each does one job — pick by what you have and what you want to do:

Step by step:

• Self-signed — name it, enter the server's hostname, pick a key type and how long it's valid, then Create certificate. Others won't trust it automatically; for that use Request from a CA.
• Request from a CA — enter the hostname (and any other hostnames), click Generate request, and download the .csr and .key files. Send the .csr to your certificate authority. When they send the signed certificate back, come back and use Import key + cert (paste the .key you saved plus their certificate).
• Install CA reply — for when the certificate request was made where the key lives, so the CA returned only a certificate and the private key stays put. Choose the key entry the request came from — Claridex lists the keystore's key entries and selects it for you when there's only one, so there's no alias to remember or type. Don't have a request yet? Click Generate CSR for this entry to make one from that entry's existing key, send it to your CA, and come back with their reply. Paste the signed certificate (and any intermediates), then Install certificate. The private key stays in the keystore; only the certificate is updated.
• Import key + cert — when you have both a certificate and its private key file. Name it, paste the private key, paste the certificate (your cert first, then any intermediate certificates), then Import. Claridex checks the key and certificate match before saving.
• Trust a certificate — make the server trust someone else's certificate: a trading partner's, or the authority that issued it. Name it, paste their certificate (no private key), then Import. Use this when your server connects out to a partner that uses a private or self-signed certificate, or to accept a partner's client certificate. If your Mirth has a separate truststore, its card has its own + Import for the same thing.
• Renew (on a certificate row) — the quickest way to update an existing server certificate; the entry is already chosen for you. For a self-signed entry it re-issues a fresh certificate in place. For a CA-signed entry it asks for the newly signed certificate your CA returned and installs it onto the same key (the private key stays put) — the same result as Install CA reply, reached straight from the row that's expiring.
• Replace (on a trusted-certificate row) — when a partner or CA rotates a certificate you trust, click Replace on that row and paste their new certificate. It swaps in the new one under the same name in a single step. Your server's own certificate is untouched.

Self-signed and the CA request let you choose the key type: RSA-2048 (the default), RSA-3072, RSA-4096, EC P-256, or EC P-384 — all SHA-256 signed.

Editing the keystore is not the same as Mirth using the new certificate. Mirth loads its keystore when it starts, and each connector (and the admin console) is configured to use a specific entry. After you change the server's own certificate, make sure Mirth is pointed at that entry and restart Mirth so it picks it up; trusting a certificate usually also takes effect on restart. To add TLS to a connector without touching Mirth's own certificates or restarting it, use the Connectors tab (§9) instead — that runs a TLS proxy in front of Mirth with its own certificate.

7.2 Renewing an expiring server certificate

When your server's own certificate is about to expire, everything comes down to one question: where is the private key that pairs with the new certificate? The private key never leaves your server, so renewing is really just getting a freshly signed certificate that matches a key Claridex can put back in the keystore. There are two clean routes, plus one common dead-end and how to get out of it.

Route 1 — Renew straight from the row (the key is already in the keystore). Use this when the entry already appears on the Servers page as a working key entry (it shows a key type and an expiry date).

• Self-signed entry: click Renew on the row and confirm. A fresh certificate is issued on the same key. Nothing to paste.
• CA-signed entry: click Renew and it asks for the newly signed certificate your CA returned, then installs it onto the same key. To get that certificate you need a signing request made from the key already in this keystore. Claridex can make one for you: click Generate CSR for this entry in the Renew dialog, send the downloaded .csr to your CA, then paste their signed certificate back. The private key never changes, which is what you want when a trading partner has pinned it. (If you would rather use a fresh key, use Route 2 instead.)

Route 2 — Request a new certificate from Claridex, then import it (recommended when you are starting clean). This is the reliable end-to-end path that needs nothing outside Claridex.

1. Server certificate card, + Add, Request from a CA. Enter your server's hostname (and any other hostnames), then Generate request. Claridex gives you two files: a .csr and a .key. Save both. The .key is the private half, and it is what pairs with whatever the CA signs, so keep it safe.
2. Send the .csr to your certificate authority. When they send the signed certificate back, also ask for the intermediate CA certificate(s).
3. Server certificate card, + Add, Import key + cert. Paste the .key from step 1 and the signed certificate (your certificate first, then the intermediates), then Import. Claridex confirms the key and certificate match before saving, and the expiring entry is replaced.

Which route uses "Install CA reply"? Route 1's CA-signed case. "Install CA reply" installs a certificate onto a key that is already in the keystore. Use it whenever you want to keep the exact same key: click Generate CSR for this entry (in the Renew dialog or the Install CA reply screen), send that .csr to your CA, then paste their reply. It also fits a request made outside Claridex (with keytool or Mirth) where the CA returned only a certificate. If instead you made a fresh request with Request from a CA (Route 2), the matching key is the .key file you saved, so use Import key + cert, not Install CA reply.

The common dead-end: you have only a .cer and no key file. Many CA or reseller renewal portals generate their own private key and send back only a certificate. That certificate does not pair with the key in your keystore, so Install CA reply refuses it with "the certificate's key doesn't match this keystore entry," and Renew on a CA-signed row will not take it either. Two ways forward:

• If the portal can also give you the private key (usually inside a .pfx or .p12), use Import key + cert with that key and certificate.
• If no one has a matching key, start over cleanly with Route 2: use Request from a CA in Claridex to make a fresh .csr and .key, have the CA sign that .csr, then Import key + cert. Because the key came from Claridex this time, everything matches.

Always send the whole chain. When the CA returns your certificate, paste your certificate first and then the intermediate CA certificate(s). A lone certificate with no chain is the usual cause of "couldn't establish the certificate chain." If you genuinely only have the leaf certificate, import the issuing CA under Trust a certificate first, then retry.

After you replace the server's certificate, restart Mirth so it loads the new one (see the note above).

8. Connect a server's Mirth admin API

Required for the Connectors page (and channel redeploy). Folder discovery sets up keystores only — the connector list needs the live admin API.

1. On the Connectors page, click Connect to Mirth (or Edit Mirth connection to change an existing one). This is also the final step of Add a server (§6).
2. Enter the server's Admin API URL (e.g. https://localhost:8443/api), username, and password.
3. For the cert: provide a CA certificate path to trust it (recommended), or check Allow self-signed (convenient for a dev cert, but it disables TLS verification on the admin connection — avoid in production).
4. Test & connect — it logs in to verify before saving.

9. Per-connector TLS (the managed stunnel proxy)

Adds TLS to a Mirth connector without changing Mirth.

On the Connectors page, each connector shows a TLS / Plaintext badge. Click Enable TLS:

• Inbound listener (source): the proxy accepts TLS on a listen port and forwards plaintext to Mirth's existing listener. Point external senders at the new TLS port — no Mirth change.
• Outbound sender (destination): the proxy accepts plaintext locally and sends TLS to the peer; it can re-point the Mirth connector for you via the admin API (and restore it if you later disable TLS).

Details:

• Any port. Pick whatever listen port your environment uses — there's no range restriction. The app opens exactly that port in the Windows firewall for the life of the binding (and closes it on disable), so it's reachable and no unused ports are left open.
• The proxy needs a certificate to present. By default Claridex generates a self-signed certificate and its private key for you; afterward send the other side your public certificate (via View certificate, §9.4) so they trust it. This is the right choice for most cases.
• To use your own certificate instead, choose Import my own and paste the certificate together with its matching private key. A certificate and its key are one pair, created together, so you cannot supply a certificate on its own and have a key made for it. You have both when you generated a key and CSR that your CA then signed, or when you have a .pfx / .p12 that bundles the certificate and key. A trading partner should only ever send you their public certificate or CA, never a private key, so a bare .cer from a partner cannot be used as the proxy's own identity: obtain the .pfx that also contains the key, or generate a self-signed certificate and share your public one.
• Mutual TLS is supported: provide the peer CA to also require and verify the other side's certificate.
• A secured connector shows "TLS · proxy" and a Secured label instead of another Enable-TLS button. If that binding's far end is unreachable it reads "TLS · down" instead — see §9.3.
• Renew re-issues the proxy cert in place; Disable removes the binding (and its firewall rule, and any auto re-point).

9.1 Test the connection before you save

Both the Enable TLS and Edit dialogs have a Test connection button under the target address. Use it — a binding whose far end can't be reached will still look "secured" in the UI while messages go nowhere, and this is the cheapest way to find that out before it matters.

There's also a Test listen address button under the Listen field: it checks whether that port is free to bind, so you catch a conflict with another program before you save. (If you test a port your own proxy is already using, it will say so — that's expected.)

What the forward-side test does depends on the direction:

• Outbound (destination): performs a real TLS handshake with the partner, presenting your certificate if you pasted one. On success it reports the negotiated protocol and cipher, and the far end's common name, issuer and expiry date — so you can confirm you reached the system you meant to.
• Inbound (source): checks that Mirth's own plaintext listener — the one the proxy will forward decrypted messages to — is actually accepting connections.

Nothing is saved by testing. It's safe to run as often as you like.

Reading the result. The message tells you what to change, not just that something failed. The ones you're most likely to see:

9.2 Edit a binding

Each row in the TLS bindings table has an Edit action. You can change the binding's name, either address, the mutual-TLS settings, and the minimum TLS version — with the same Test connection button available in the dialog.

• The certificate is not editable here. Use View certificate to see it, Renew cert to reissue a Claridex-generated one, or Replace cert to install a different one. Keeping those separate makes it unambiguous which change you're saving.
• Changing the listen address moves the endpoint. Anything still pointed at the old address stops working. If Claridex re-pointed a Mirth connector for you when you enabled TLS, it re-points that connector automatically; the dialog tells you which case you're in before you save. If the Mirth server can't be reached at that moment the edit still saves and you get a warning telling you to re-point it by hand.
• Mutual TLS can't be half-configured. Turning it on without a peer CA on file is refused — a binding that verifies peers with nothing to verify against would reject every connection. Leave the CA box blank to keep the one already stored.

Saving reloads the proxy, so connections through that binding are briefly interrupted.

9.3 The TLS bindings table

The Status column shows two indicators, because a binding can fail in two different ways an operator needs to tell apart:

• TLS — is the encrypted wire actually working? For an inbound binding this is a real TLS handshake against your own listener; for an outbound binding it's a handshake to the partner. A TLS · Down here with Mirth · Up is the tell-tale of a broken or expired certificate — the connector reaches Mirth fine, but the encryption itself isn't serving. (Mutual-TLS bindings show a Yes in the mTLS column and can't be wire-checked automatically; use Test connection.)
• Mirth / Peer — can the proxy deliver? For an inbound binding this is Mirth's own listener; for an outbound binding it's the trading partner. This is what drives fail-fast withholding (§9.5).

"Unknown" never means "fine." If the proxy service stops, its last report is deliberately treated as out of date rather than as good news, so a stopped service can't leave the page showing a reassuring green Up.

Certificate — when this binding's certificate expires, shown as valid / expiring-soon / expired. Hover for the exact date and the certificate's common name. An expired proxy certificate will cause the other side to reject connections, so treat amber here as work to schedule.

The status column refreshes on its own every few seconds; you don't need to reload the page.

9.4 Share your certificate with a trading partner

When Claridex generates a self-signed certificate for a binding, the other side has no reason to trust it yet. Making it work is a one-time exchange: you send them your certificate, they add it to their trust store.

A certificate is public — it's designed to be handed out. Your private key is the secret, it never leaves this machine, and Claridex will not show or export it under any circumstances.

1. On the Connectors page, find the binding and click View certificate.
2. Check the details — subject, issuer, validity, and whether it's self-signed.
3. Download .pem (or Copy) and send the file to your partner.
4. Verify the fingerprint out of band. The dialog shows a SHA-256 fingerprint. Read it to your partner over a different channel than the one you sent the file on — a phone call, not the same email thread. They compute the fingerprint of the file they received; if the two match, nobody altered it in transit. If you only ever use one channel, this check proves nothing.
5. They import it as a trusted certificate on their side.

Renewing creates a new certificate, and it takes effect immediately. When you click Renew cert (or Replace cert), the proxy reloads and serves the new certificate right away — no service restart. The catch is the other side: their trust store still holds the old certificate, so connections will start failing until they re-import. Plan a rotation as a two-sided change: renew, send the new certificate, have them re-import, then cut over. Claridex-generated proxy certificates are valid for about 825 days (~27 months), and the Certificate column warns you well before that.

If your partner issued you a certificate to present (a client credential for mutual TLS), you need it with its private key, for example inside a .pfx. Use Replace cert to install the certificate and key together. Renew cert no longer applies to that binding, since it isn't ours to reissue. A partner never sends you a private key for a certificate they present to you: you only ever receive their public certificate or CA for that.

9.5 What happens when the far end is down

A proxy must never accept a message it can't deliver — that would look like success to the sender while the message is silently lost. So the proxy continuously checks each binding's downstream (the peer for an outbound binding, Mirth's own listener for an inbound one) and, after a few consecutive failures, stops listening for that binding until the downstream recovers.

What you'll see while a downstream is unreachable:

• The binding shows Down (and Down · offline once its listener has been withdrawn) in the bindings table, and the secured connector reads "TLS · down" — see §9.3.
• The binding's listen port stops accepting connections. Senders get an immediate connection refused rather than a socket that swallows the message.
• Mirth marks the message errored and applies its own queue/retry — the behaviour your team already knows, instead of a false "Sent". That refusal is the error signal; no extra configuration is needed to make Mirth queue.
• The port comes back automatically once the downstream answers again. A brief blip won't take a binding down; it takes several consecutive failures.

Waiting for the ACK is still what guarantees delivery. A sender configured to ignore the response (e.g. a Mirth TCP Sender with Ignore Response = Yes) treats a local write as success, so the very first message after a far-end failure can still be lost before the listener is withdrawn. For interfaces where delivery matters, leave the sender waiting for its ACK — an end-to-end acknowledgement is the only true confirmation the far end received the message.

10. Expiry notifications

Notifications (under the Settings menu):

• Thresholds — days-before-expiry to alert, comma-separated (e.g. 30, 14, 3).
• Channels — Email (SMTP), Webhook, Slack (incoming webhook). Configure and Send test to verify.
• Current alerts — the certificates Claridex is monitoring that fall within a warning window right now. This covers the proxy binding certificates and the keystore certificates found when you added each server.

Run it on a schedule: point a scheduler (Windows Task Scheduler) at the run endpoint daily, with the shared token (NOTIFY_TOKEN, >= 24 chars; see §12):

Invoke-WebRequest -Method POST -Headers @{ "X-Notify-Token" = "<token>" } `
  http://localhost:8800/api/notifications/run

11. Backup & restore

• C:\ProgramData\ClaridexCertificateManager\config.json — holds your server config, store passwords, and the per-connector TLS proxy keys (written 0600). Back this up. It's the one file you can't regenerate.
• The app writes a timestamped keystore backup next to each managed keystore before mutating it.
• To restore: reinstall, then drop your saved config.json (and license.key, auth-secret, admin-password.hash) back into the data dir and restart the services.

12. Configuration reference

The app reads its settings from the ClaridexCertificateManager service's environment, stored by NSSM (in the install dir) as one combined block. View/change it, then restart the service:

# 1) SEE the current variables first (one KEY=VALUE per line)
& "C:\Program Files\ClaridexCertificateManager\nssm.exe" get ClaridexCertificateManager AppEnvironmentExtra
# 2) SET the whole block back with your line added/changed, then restart
& "C:\Program Files\ClaridexCertificateManager\nssm.exe" set ClaridexCertificateManager AppEnvironmentExtra <all existing KEY=VALUE pairs + your change>
& "C:\Program Files\ClaridexCertificateManager\nssm.exe" restart ClaridexCertificateManager

AppEnvironmentExtra is one block, not per-variable. set replaces the whole value, so setting a single KEY=VALUE wipes the rest (PORT, AUTH_SECRET, the tool paths…) and the app won't start. Always read it first and put your change back alongside the existing pairs. Wherever an example below shows a leading ..., that stands for those existing pairs — keep them.

Data directory layout (C:\ProgramData\ClaridexCertificateManager\): config.json, license.key, auth-secret, admin-password.hash, stunnel\ (generated proxy config + cert PEMs), and the service logs.

13. Upgrades

Run the new setup.exe over the existing install. It upgrades in place (stops the services first so files aren't locked, then re-registers and restarts them). Your data dir is preserved.

14. Uninstall

Use Add or remove programs -> Claridex Certificate Manager -> Uninstall. It removes the services and the TLS firewall rule but leaves the data directory in C:\ProgramData\ClaridexCertificateManager (config + license + keystores). Delete it manually for a full wipe.

15. Remote access & hardening

Out of the box the app is localhost-only (127.0.0.1:8800, plain HTTP) — safe on a single admin machine. Everything below is for exposing it to a team or hardening a production install.

15.1 Put HTTPS in front (required for remote access)

The app speaks plain HTTP and its sign-in cookies require HTTPS, so never expose port 8800 directly. Instead, run a TLS-terminating reverse proxy on the same host that forwards to 127.0.0.1:8800, and tell the app its public URL:

& "C:\Program Files\ClaridexCertificateManager\nssm.exe" set ClaridexCertificateManager AppEnvironmentExtra `
    ... AUTH_URL=https://certs.hospital.org
& "C:\Program Files\ClaridexCertificateManager\nssm.exe" restart ClaridexCertificateManager

AUTH_URL is the public HTTPS URL users browse to; it's used to build login/SSO redirects. (trustHost is already enabled, so you don't need AUTH_TRUST_HOST.) Keep the app bound to loopback — leave HOSTNAME=127.0.0.1 (the default).

Minimal proxy examples (point your own TLS cert at it):

# nginx
server {
  listen 443 ssl;
  server_name certs.hospital.org;
  ssl_certificate     C:/certs/certs.crt;
  ssl_certificate_key C:/certs/certs.key;
  location / { proxy_pass http://127.0.0.1:8800; proxy_set_header Host $host; }
}

# Caddy (auto-HTTPS)
certs.hospital.org {
    reverse_proxy 127.0.0.1:8800
}

IIS works too (Application Request Routing + URL Rewrite as a reverse proxy).

Need the app on a port other than 8800 behind the proxy? Change the PORT variable and restart the service (see §12).

15.2 Single sign-on (Google / Microsoft Entra)

With HTTPS in place you can add SSO and turn password login off. Set the provider env on the app service (via nssm ... AppEnvironmentExtra, then restart):

• Google: AUTH_GOOGLE_ID, AUTH_GOOGLE_SECRET
• Microsoft Entra: AUTH_ENTRA_ID, AUTH_ENTRA_SECRET, AUTH_ENTRA_ISSUER
• Restrict who gets in: AUTH_ALLOWED_DOMAINS=hospital.org and/or AUTH_ALLOWED_EMAILS=alice@hospital.org,bob@hospital.org
• Disable the built-in password login once SSO works: AUTH_PASSWORD_LOGIN=off

Register these redirect URIs with the provider (scheme + path must match exactly):

• Google → https://<your-host>/api/auth/callback/google
• Microsoft → https://<your-host>/api/auth/callback/microsoft-entra-id

Creating the OAuth apps themselves is done in the provider's own console — the Google Cloud Console (APIs & Services → Credentials) or the Microsoft Entra admin center (App registrations), where you generate the client ID/secret and register the redirect URIs above. Want a hand setting it up? Email support@claridex.co.

15.3 Trust Mirth's cert properly

For the Mirth admin connection (§8), prefer a CA certificate path over Allow self-signed. allowSelfSigned turns off TLS verification on that connection (a MITM risk, and the app logs a warning). To trust it instead: export the CA that signed Mirth's admin cert to a PEM, put it somewhere the service can read, and set it as the CA certificate path in Connect to Mirth.

15.4 Limit discovery

Set MIRTH_DISCOVERY_BASE so "Add server" can only read Mirth installs under one folder tree (§6 / §12).

16. Troubleshooting

Still stuck? Email support@claridex.co with the symptom and the relevant log lines (above), and we'll help. The latest installer is always at https://claridex.co/download.