libCurl error with self signed certificate on remote HTTPS peer

Google Groups archive
1

Environment : 2 x Ubuntu 16.04.6 servers running under VirtualBox, Orthanc ApiVersion 5 using MySQL plugin

I’m testing an Orthanc server (“ORTH-A” and thinking that this would be a “front end” server that modalities would send to) and it’s peering with another Orthanc server (“ORTH-B” back end server), using the (excellent) online documentation.

ORTH-B* has been installed behind an Apache reverse-proxy (“/TEST/”), Apache configured with a self signed (no password required) certificate as I’m still in a dev environment and there’s a chance that this server would not be on the same network as ORTH-A. To ensure that the reverse-proxy on ORTH-B is working correctly, I can browse to https://ORTH-B_IP/TEST/ and I get the prompt to log into the Orthanc Explorer, which I can successfully do. I configure the API credentials that ORTH-A is going to connect to ORTH-B with, and test them against the Orthanc Explorer and once again, I get logged in.

I now jump onto ORTH-A and configure it with the following (the self-signed files were downloaded from ORTH-B and the CertificateFile confirmed as being in PEM format**)

`

…
“OrthancPeers” : {
“ORTH-B” : {
“Url” : “https://ORTH-B_IP/TEST/”,
“Username” : “ORTHA”,
“Password” : “ORTHAPASSWORD”,
“CertificateFile” : “self-signed.pem”,
“CertificateKeyFile” : “self-signed.key”

}

},
…

`

Restarting Orthanc and then testing (through postman, configured to ignore self signed certificate verification) what peers it’s configured with (using API call /peers?expand) I certainly see the ORTH-B peer with it’s details (Password is null which I presume to be correct and for security purposes).

{
“ORTH-B”: {
“CertificateKey”: “self-signed.pem”,
“HttpHeaders”: ,
“Password”: null,
“Pkcs11”: false,
“Url”: “https://ORTH-B_IP/TEST/”,
“Username”: “ORTHA”
}
}

All well, so far. Now (as per the documentation) I can use a call to test connectivity to that peer (using API call /peers/ORTH-B/system) without actually sending DICOM (nice!) but it fails with:

{
“Details” : “libCURL error: Problem with the SSL CA cert (path? access rights?)”,
“HttpError” : “Internal Server Error”,
“HttpStatus” : 500,
“Message” : “Error in the network protocol”,
“Method” : “GET”,
“OrthancError” : “Error in the network protocol”,
“OrthancStatus” : 9,
“Uri” : “/peers/ORTH-B/system”
}

BTW : when I try (in postman and through a browser) to check https://ORTH-B/TEST/system, I get the expected response.

If it helps, U16-04.6 uses curl 7.47.0 although I’m not sure that Orthanc is likely to use what’s installed on the system, rather the library it’s been compiled with. I’ve also gone through adding this self signed certificate using this SO post to both servers but still no joy.

I’m now at a loss as to why I’m getting this error message. Any guidance from anyone??

Kindest regards,

Dave

2

Hi Dave,

Hard to tell without doing a full analysis of your system.
May I advise you to have a look at this sample: https://bitbucket.org/osimis/orthanc-setup-samples/src/efb63a4de0598a83b8be23cb10b91df1165e4ee2/docker/full-tls/ that basically does what you’re trying to do (just skip the part with the lua script and forward proxy that are out of scope for your issue).

Eventually, you could try to modify this setup to match yours and submit it to us if you still have the issue.

Best regards,

Alain.

3

Hi Dave,

The error message is actually telling what’s wrong: “libCURL error: Problem with the SSL CA cert (path? access rights?)”.
The CertificateFile and CertificateKeyFile should be the full path and name of the files, not only the file names.
Also I think the CertificateKeyPassword is a mandatory field. You can put any value if you CertificateKeyFile does not come with any password, and then the libCurl will just ignore it.

So you might probably be willing to modify your setup the following way:

…
“OrthancPeers” : {
“ORTH-B” : {
“Url” : “https://ORTH-B_IP/TEST/”,
“Username” : “ORTHA”,
“Password” : “ORTHAPASSWORD”,
“CertificateFile” : "/path/to/self-signed.pem",
“CertificateKeyFile” : "/path/to/self-signed.key",
“CertificateKeyPassword”: “‘’”
}

},
…

I hope this helps!

Cheers,

Michel

4

Michel,
Thanks for the response. I’ve updated the config to use the full path names. Additionally, I had assumed that “CertificateKeyPassword” was a full path to a file that contained the password, rather than the actual password being entered in this config.

Unfortunately, getting the same error.

5

CertificateKeyPassword is the password, not the file containing it.

6

Yup understood.
I’m currently in the process of setting up ORTH-B to use a public certificate in the hope that I don’t have to use these Certificate* settings at all (it wouldn’t be a self-signed certificate) … will let you know how I get on.

Can I take it that you’ve gone through this process (using self-signed certs?)

7

I did recently setup a certificate on client side (say a sender Orthanc) signed by a CA setup on server side (say a receiver Orthanc) to add a layer of client authentication to send studies between two Orthanc servers in DICOMweb (which uses same settings as peering used in your case).

8

So I decided a reset would be in order just so that I’m clear as to what I’ve done and it’s working, I’ve documented as I’m sure I’ll need to come back and check this again!

I’ve rebuilt ORTH-B. Once again it’s sitting pretty on HTTP port 8042 behind an Apache proxy that has now been configured with a publicly signed X509 certificate. From a browser, I downloaded the certificate chain (3 in total) and converted them from .CER to a combined .PEM file.

On ORTH-A I’ve also gone back to square one. I am not using client certificate authenticating (at present), so I didn’t need to have CertificateFile, CertificateKeyFile or CertificateKeyPassword configured because Orth-B isn’t checkng the client’s certificate (again I hope I’m reading this right).

What threw me was that in the documentation I read, there’s no mention of the following settings that I’ve been looking at in the orthanc.json file:

  • HttpsCACertificates : “”; at the moment this is still empty and, again if reading correctly, I should only have to set this if I’m using self-signed certificates which I’m not now.

In testing, I had turned HttpsVerifyPeers to false and checked ORTH-A’s peers, and sure enough it works in postman. This is good. So I set HttpsVerifyPeers back to true. Test again, and sure enough I get my “Problem with the SSL CA cert” issue. At this point I can only assume that it’s the HttpsCACertificates setting, so I set this to the file path of my download certificate chain.pem file and … we’re all good.

I’ve written this all down in a document and will probably go through the whole process again, this time with self-signed certs - I think it was definitely the HttpsCACertificates setting that was blank and was throwing me for a loop. IMHO I think this should be mentioned in the documentation.

9

Dave,

Please review your own documentation and once it’s all fine, please share it here and I will work on updating the Orthanc Book with more info :slight_smile:

Thanks for your contribution!

Cheers,

Michel