Mutual TLS for DICOM connections

Standard HTTPS — the kind your browser uses every day — only proves the server’s identity to the client. The server never verifies who the client is beyond, at most, a password or API key sent after the connection is already open.

For a DICOM connection carrying real patient imaging data from a hospital’s scanner over the public internet, that one-sided trust isn’t enough. Mutual TLS (mTLS) closes that gap by having both sides prove their identity before any data moves.

What makes it “mutual”

In regular TLS, the server presents a certificate, the client checks it against a trusted certificate authority (CA), and the connection proceeds. The client’s own identity, if checked at all, is verified later — inside the already-encrypted connection, with a password or token.

mTLS adds one more step before that connection opens:

• The server presents its certificate, as before.
• The client presents its own certificate, signed by a CA the server trusts.
• The server verifies the client’s certificate before completing the TLS handshake — before a single byte of DICOM data is exchanged.

Both sides end the handshake knowing exactly who they’re talking to, cryptographically, not just by network address or a bearer token that could have leaked.

Why this matters specifically for DICOM

A hospital’s CT scanner, MRI console, or PACS is a piece of hardware sitting on someone else’s network, connecting out to your service over the internet. You have no way to verify “this really is St. Mary’s Radiology’s scanner” from an IP address alone — IP addresses change, get NATed, or get spoofed. A client certificate tied to that specific device doesn’t have that problem: only the holder of the matching private key can complete the handshake.

This also solves a routing problem that’s specific to services receiving DICOM from many different senders: which sender is this, and where should their studies go? Each client certificate identifies exactly one authenticated device. A connection either presents a certificate that’s recognized and mapped to a destination, or the handshake is rejected outright. That check happens before any DICOM association opens and before any imaging data is touched.

What this looks like in practice

Setting up mTLS for a DICOM sender means:

1. Generating a certificate and private key for that specific device (scanner, PACS, or workstation).
2. Installing the certificate and key on the sending device, alongside the certificate authority the device should trust on the server side.
3. Configuring the device to open its DICOM connection with TLS enabled and present that certificate — most modern DICOM software (including open tools like DCMTK’s storescu) supports this natively.

From there, every connection attempt is either a recognized, certificate-authenticated device or it’s rejected — there’s no in-between state, and no unauthenticated DICOM traffic reaches your service at all.

How this fits with STOW-RS delivery

mTLS secures the inbound leg — the hospital-facing DICOM connection. It’s a separate concern from how the instance eventually reaches your own service, which is typically over standard HTTPS as a STOW-RS HTTP POST request. See how hospitals transmit DICOM over the internet for how the two pieces combine end to end.

Dicomly issues and manages the per-device client certificates for you. They’re auto-provisioned when you add a sender, and you can rotate or revoke them independently per device. That gets you certificate-based authentication on every connection without running your own certificate authority.

Next steps

See the endpoints and certificates concept guide for how certificates map to senders, or request early access to provision your first mTLS-secured endpoint.