Trying to Setup Additional Instance of Orthanc using ssl for REST & TLS for DIcom.

Setting up additional instance of Orthanc without using NGINX as proxy. It is running within a Docker Container with exposed ports. Trying to get TLS working natively on that instance of Orthanc.

ports: [“4446:4242”,“8042:8042”].

For the REST API: (All seems to be working since I have an SSL with valid cert on https://localhost:8042.

“SslEnabled” : true,
“SslCertificate” : “/etc/orthanc/combined_crt.pem”,
“HttpsVerifyPeers”: false,

For DICOM, trying to test a few different arrangements.

  1. Locally with HOROS as a SCU. It has some TLS support, but the more recent version of HOROS are kind of buggy since recent releases of OSX.

  2. In live setup using a vendor’s Cloud as a SCU. That is sending requests through a Router that forwards the WAN port to the LAN where the PACS server is. That is probably most background, because there is connectivity now when TLS is enabled, but I am getting some errors in the Orthanc Log file.

Basic Setup for DICOM for testing is as follows, about as permissive as possible initially.

“DicomTlsEnabled” : true,
“DicomTlsCertificate” : “/etc/orthanc/scp.crt.pem”,
“DicomTlsPrivateKey” : “/etc/orthanc/scp.key.pem”,
“DicomTlsTrustedCertificates” : “/etc/orthanc/scu.crt.pem”,
“DicomTlsRemoteCertificateRequired” : false,
“HttpsCACertificates” : “/etc/orthanc/ca-certificates.crt”,
“DicomCheckModalityHost” : false,
“DicomCheckCalledAet” : false,

In the orthanc log:

I0821 04:56:08.368898 DicomServer.cpp:498] (dicom) Setting the TLS certificate for DICOM SCP connections: /etc/orthanc/scp.key.pem (key), /etc/orthanc/medical.ky.crt.pem (certificate)
I0821 04:56:08.368923 DicomServer.cpp:548] (dicom) Setting the trusted certificates for DICOM SCP connections: /etc/orthanc/scp.crt.pem
I0821 04:56:08.369103 DicomServer.cpp:404] (dicom) Orthanc SCP will use DICOM TLS
I0821 04:56:08.369152 DicomTls.cpp:83] (dicom) Initializing DICOM TLS for Orthanc SCP
W0821 04:56:08.371683 main.cpp:1249] DICOM server listening with AET BUTTERFLY_SCP on port: 4242, exposed port is 4446

and a little further down:

I0821 04:56:08.371813 HttpServer.cpp:1890] (http) Minimal accepted version of SSL/TLS protocol: TLS1.2
I0821 04:56:08.371823 main.cpp:1077] (http) No configuration option “SslCiphersAccepted”, will accept the FIPS 140-2 ciphers
I0821 04:56:08.371834 HttpServer.cpp:1916] (http) List of accepted SSL ciphers: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-SHA:AES128-SHA

When I try to ECHO from the SCU I see:

E0821 04:56:58.305518 CommandDispatcher.cpp:283] Receiving Association failed: DUL secure transport layer: tlsv1 alert unknown ca

in the Orthanc log, and:

pacs-butterfly_1 | D: Association Received: xxx.xxx.xxx.xxx
pacs-butterfly_1 | D: setting network send timeout to 60 seconds
pacs-butterfly_1 | D: setting network receive timeout to 60 seconds

in the terminal where I started up Docker in the Foreground.

Looked over this page a few times and kind of stumped at the moment. Probably not that hard to setup once you’ve done it a couple of times ?

https://book.orthanc-server.com/faq/dicom-tls.html#id1

Looks like I seem something similar when I try on my local development clone via the CLI:

E: TLS client handshake failed
F: Association Request Failed: 0006:031b Failed to establish association
F: 0006:0317 Peer aborted Association (or never connected)
F: 0006:031e DUL secure transport layer: certificate verify failed

E0821 05:08:18.904195 CommandDispatcher.cpp:283] Receiving Association failed: DUL secure transport layer: tlsv1 alert unknown ca

I’ll read through it all again, but that seems to be main issue at this point.

Thank you.

As a follow up to my previous post, I am able to get a verified ECHO from the CLI with:

echoscu -v domain/ip port --anonymous-tls --ignore-peer-cert +cf Butterfly_SCP_Cert.pem

I: Requesting Association
I: Association Accepted (Max Send PDV: 16372)
I: Sending Echo Request (MsgID 1)
I: Received Echo Response (Success)
I: Releasing Association

whereas:

echoscu -v domain/ip port --anonymous-tls +cf Butterfly_SCP_Cert.pem

fails with:

E: TLS client handshake failed
F: Association Request Failed: 0006:031b Failed to establish association
F: 0006:0317 Peer aborted Association (or never connected)
F: 0006:031e DUL secure transport layer: certificate verify failed

“DicomTlsRemoteCertificateRequired” : false, is set to false.

I suspect that it maybe has something to do with the fact that I am running that Orthanc Instance in a Docker Container and I don’t have the CA Bundle or the CA’s configured correctly within that container.

I take it: “HttpsCACertificates” : maybe only applies to the REST API CA’s or I don’t have it setup correctly yet for TLS.

Yes, HttpsCACertificates only applies to the Rest API.

The DicomTlsTrustedCertificates should contain all trusted certificates concatenated so I guess this should also include the public root CAs of well-known providers. You can get all these public root CAs from here: https://curl.se/docs/caextract.html.

Disclaimer: not tested. I’ve never tried DICOM TLS with a public CA.

Your certificate needs to be generated based on the external domain that it will work on, for example:

example “.domain.com”

It is important that the .pem file is global “_*domain.com” and that it is registered on your server in the root folder of certificates from trusted sources.

Furthermore, in certain cases, there is no need to point the “.crt” file, simply pointing the .pem and .key files correctly, respecting their respective operating system (For Linux left slashes . For Windows, two forward slashes right)

It is also important that the mysql and postgress plugins are compatible with the version of Orthanc installed.