Question: Issues with Orthanc DICOM TLS Connection
1. Background
I’m trying to establish a DICOM connection using TLS between an Orthanc DICOM server and a C# fo-dicom client.
2. Test Results So Far
Successful Cases:
The connection works successfully when TLS is disabled.
I created a self-signed certificate for localhost, trusted it on the client, and successfully connected using the localhost address.
Failed Cases (Current Problem):
I’ve installed a Let’s Encrypt SSL certificate (fullchain1.pem, privkey1.pem) issued by Certbot on the Orthanc server.
Even after registering the certificate as trusted on the client, the connection consistently fails.
3. Error Messages
Server Log:
E0820 07:30:17.478053 CommandDispatcher.cpp:283] Receiving Association failed: DUL secure transport layer: unspecified TLS error
Client Log:
System.ComponentModel.Win32Exception: The message received was unexpected or badly formatted.
4. My Question
Why do I succeed with a self-signed certificate but fail with a valid SSL certificate issued by Certbot? Specifically, what could be causing the unspecified TLS error and unexpected or badly formatted message errors, even after the client has been configured to trust the certificate? What should I check next to resolve this issue?
From your description, your TLS setup in Orthanc works with self-signed certificates but fails when using a valid certificate (e.g., Let’s Encrypt). This behavior usually points to an issue with certificate chain, key format, or algorithm compatibility, rather than a problem with TLS itself in Orthanc.
DicomTlsCertificate should point to the public certificate file (.crt).
DicomTlsPrivateKey should point to the corresponding private key without a passphrase.
DicomTlsTrustedCertificates should include all trusted public certificates, usually concatenated in a single .crt file.
If Orthanc acts as an SCU, you need to set "UseDicomTls": true in the DicomModalities block.
Certificate chain
Certificates from authorities like Let’s Encrypt often come with one or more intermediate certificates. If the chain is not correctly configured, either the client or the server may reject the connection.
Ensure the certificate used by Orthanc contains the complete chain (server + intermediates).
Make sure the file configured in DicomTlsTrustedCertificates includes all necessary intermediate certificates.
Protocol / algorithm compatibility
Depending on the Orthanc version (and its OpenSSL library) and the client (fo-dicom), there may be incompatibilities in algorithms or TLS versions (e.g., TLS 1.2 vs TLS 1.3, specific elliptic curves, or signature algorithms).
The Orthanc Book notes that some versions of DCMTK have known issues with DICOM TLS. Even if you are using fo-dicom, similar issues could occur depending on the .NET TLS implementation.
Private key
Ensure that the private key used in Orthanc does not have a passphrase and is in the expected PEM format.
Additional options
Since Orthanc 1.9.3, DicomTlsRemoteCertificateRequired can be set to false to allow connections without a client certificate (“anonymous TLS”), useful for debugging.
Note that DICOM TLS is independent from HTTPS/TLS configuration; the two are separate within Orthanc.
Diagnostic suggestions
Try connecting with another TLS-capable DICOM client, like echoscu +tls from DCMTK, pointing to the same Orthanc certificate. This can help determine whether the problem is specific to fo-dicom.
Enable detailed TLS handshake logging on the client to identify at which step the connection fails.
Test the Orthanc certificate directly with openssl s_client to verify that the chain is complete and accepted.
Summary:
The fact that it works with a self-signed certificate confirms that Orthanc TLS is correctly configured. The critical point is likely the intermediate certificate chain or some algorithm compatibility between Orthanc and fo-dicom. Ensuring the certificate file includes all intermediates and validating the connection with independent tools (OpenSSL, DCMTK) usually helps isolate the problem.
Same issue here. I found that Orthanc is coredumping when a certificate is configured that is not signed by itself, but by an internal CA. Why? I don’t know but I have solved it by putting a haproxy instance in front of the Orthanc server. Needed to have that anyway, and the traffic behind the proxy can be unencrypted on this single machine configuration.
