https between two computers on the same network

Google Groups archive
1

Hello All,

I’m having some issues configuring two instances of orthanc (separate computers) for https.

I can query/push/pull between these two computers (each with an Orthanc server set up) using the Rest API through http.

And I can configure an orthanc instance for https only and query locally on one computer after generating an SSL certificate per these instructions: https://book.orthanc-server.com/faq/https.html

However, I would like to securely query and transfer data using the Rest API with https between servers on different computers on the same network. The documentation at the link (above) only had an example for the configuration on localhost, not how to approach the certificate handling for remote connections… I believe that is what I am struggling with.

Thanks in advance for any guidance.

Zoë

2

There is pretty good information there about creating a self-signed certificate, and if you have certificates of your own for the domains that you are using you can use those.

You should note that that cert has both the public and private keys in it: i.e. cat /tmp/private.key /tmp/certificate.crt > /tmp/certificate.pem, which you probably did if it is working on a single machine locally.

If you set up peering and your own certs you might need to make sure this is correct for your system:

“HttpsCACertificates” : “/tmp/certificate.crt”,
// Path to the CA (certification authority) certificates to validate
// peers in HTTPS requests. From curl documentation (“–cacert”
// option): “Tells curl to use the specified certificate file to
// verify the peers. The file may contain multiple CA
// certificates. The certificate(s) must be in PEM format.” On
// Debian-based systems, this option can be set to
// “/etc/ssl/certs/ca-certificates.crt”
“HttpsCACertificates” : “”,

If you use the Securing Orthanc peers with mutual TLS authentication method: I think you need to have the client certificates in your config: “SslTrustedClientCertificates”: “trustedClientCertificates.pem”

For client certificates with a web browser: Securing Orthanc with a client certificate and access it using a Web browser

Sometimes it is helpful to look at the default orthanc.json config because there are comment in there that give a little more guidance

https://hg.orthanc-server.com/orthanc/file/Orthanc-1.11.3/OrthancServer/Resources/Configuration.json

Finally, if you turn on verbose logging there will likely be some information there that will direct you to what the problem actually is.

There are also firewall issues to consider. ping the other server from the CLI, and there a those “HttpsVerifyPeers” : true, and other settings that can be helpful for troubleshooting.

If you are using BASIC AUTH, you might check that also.

Stephen D. Scotti, M.D.

3

Thank you Stephen for this prompt reply. I will look into your suggestions

4

Thanks again. Still having trouble unfortunately.

One issue is - the orthanc https documentation page has very clear examples for testing on a local machine. When creating the ssl certificates, they advise to set the FQDM to localhost. I imagine this should be set separately when attempting to interact with a remote machine, but I am unsure how this should be changed for each server.

On each orthanc server (separate computers):
SslEnabled = true,
SslCertificate = certificate.pem (this is private key and public crt file… but is this the ssl certificate generated with “localhost” FQDM or a different name?)

I have set:
SslVerifyPeers = true
SslTrustedClientCertificates = path to certificate (this is the client certificate, but what FQDM should it have been generated with?)

HttpsVerifyPeers = false
Had originally set to true as well, but the default configuration file says that HttpsVerifyPeers should be set to false if using self-signed certificates (which I am doing, as in the example in the orthanc documentation my example).

Finally, not sure of how this changes when the client is remote and not at localhost:
{ “OrthancPeers” : { “orthanc-b” : { “Url” : “https://localhost:8043”, “CertificateFile” : “client-crt.pem”, “CertificateKeyFile” : “client-key.pem”, “CertificateKeyPassword”: “” } } }
My ultimate goal is to send data from server on computer1 to server on computer2 using restAPI using https rather than http.

Thanks in advance for any information you may have.

5

Hi Zoe,

This is really outside the scope of Orthanc. The first question, are you servers public facing? or are they only available on your local network. If they are only available on the local network, you will need to create either self signed certificates and install the other servers public certificate on the other end manually. There are some instructions on this here https://book.orthanc-server.com/faq/https.html?highlight=ssl#securing-orthanc-using-self-signed-certificate. It can be tricky to set up.

The other option is to use something like https://github.com/radiac/caman to create a single trusted internal certificate authority, which can be used to sign 2 certificates one for each server.

I use caman to do this for 30+ servers and it can still be tricky.

Hope that helps.

Cheers,

James

6

Thank you for the response. They are separate computers on the same network. I have generated and installed the certificates but the connection is still blocked.

I have one final (probably very ignorant, as I am new to this) question about the difference between a peer and a modality in orthanc.

I can get the https configuration working locally, e.g. this works just fine:

curl --cacert certificate_local.pem https://__*username*:*password*__@localhost:8042/system

And I can send data to my remote modality like:
get the https configuration working locally, e.g. this works just fine:

curl -X POST --cacert certificate_local.pem https://__*username*:*password*__@localhost:8042/modalities/__*modalityName*__/store -d seriesstring

And it sends correctly. Is this sending in an encrypted fashion over https? Or is still sending through DICOM protocol? Is it still sending it encrypted? If not, how to adjust this restAPI command to send encrypted. (assuming the peers are configured correctly in each config file on each computer)

Thanks in advance and apologies for the ignorance!

7

Hi Zoe,

The difference between a peer and a modality is the protocol used to communicate between orthanc and the remote device.

A peer will use orthanc https(s) API to communicate (https://book.orthanc-server.com/faq/features.html?highlight=peer#peers) . Whereas a modality will use DICOM networking (c-find, c-store etc…) to communicate.

Re: your ssl certificates, let’s say you have 1 orthanc servers - server1 (with server1.ip.address, server1-certificate.pem) and server 2 (with server2.ip.address, server2-certificate.pem).

On server 1 - can you use curl to connect to server 2? ie: curl https://server2.ip.address:8042/system --cacert server2-certificate.pem ? If that doesn’t work - you can add -v to the curl command which will print additional diagnostics and typically the cause for the error. Just FYI - the certificates you create need to include the IP address (https://medium.com/@antelle/how-to-generate-a-self-signed-ssl-certificate-for-an-ip-address-f0dd8dddf754) of the server as well as any domain names for the server (such as localhost).

Hope that helps.

Cheers,

James

8

To reply precisely to this question. The curl command that you have pasted instructs the Orthanc server at localhost to initiate a Dicom transfer (C-Store) of the seriesstring resource to the modality specified with modalityName (more info here)

The HTTP request itself (the very small command that tells Orthanc to initiate the transfer) is secured with https://, but the bulk of the transfer is done with the Dicom protocol and is only secure if Dicom TLS is configured correctly.

As you correctly pointed out, HTTPS and Dicom TLS are two different beasts.

The peer transfer would be done with the /peers/{peer}/store route (notice that the route is similar but /modalities/ becomes /peers/.

In that case, if the Orthanc peers are configured correctly, the transfer will be secured.

(You do not have to apologize for not knowing everything beforehand :smile: )

9

James,
I was not aware of caman. Thank you very much!