I run Duplicati on Linux. I have my own custom HTTP reporting web service that is presenting an HTTPS cert signed with my internal CA (NOT a self-signed certificate, a proper root->intermediate->leaf setup, but the root is my own, not a public root.) The root is properly installed so that update-ca-certificates adds it to the system trust. Programs like curl, wget, and even python programs “just work” without any special setup or arguments.
With Duplicati v2.0.x I could update the mono CA trust (Debian plugs mono into update-ca-trust but it’s using Mono’s certmgr at the core) and the HTTP requests worked just fine. Now with v2.1.x, the mono trust store is no longer consulted and the requests just fail. This results in the backup reporting 2 warnings to the home screen that don’t appear in the backup log, and no report being sent to my web service. I DO NOT WANT to disable SSL validation entirely, nor do I want to specify a specific certificate hash that will have to be updated on a dozen different backup clients when the certificate renews every year (maybe soon 90 days based on where chromium and Mozilla are proposing). I want to trust my root cert. How do I specify a certificate chain to trust?
You can specify what certificate hash you want to trust with the option send-http-accept-specified-ssl-hash on the Http Report Module of the advanced options of the backup.
send-http-accept-specified-ssl-hash If your server certificate is reported as invalid (e.g. with self-signed certificates), you can supply the certificate hash (SHA1) to approve it anyway. The hash value must be entered in hex format without spaces or colons. You can enter multiple hashes separated by commas.
I read that as the hash of the leaf certificate, though, correct? That’s what I would expect based on similar options I’ve encountered in other programs.
I explicitly DO NOT want to do that, because when the certificate expires every year I will have to also simultaneously update a dozen different backup clients with the new hash. That’s potentially possible (though very annoying) for the machines I directly control, but getting users to edit their configuration and get it correct all on the same day is never going to happen.
I read that as the hash of the leaf certificate, though, correct?
That’s correct, it checks leaf certificates. I believe this could be a feature request.
I have quickly searched about SSL_CERT_FILE and SSL_CERT_DIR environment variables and how they can overwrite dotnet’s behavior, but it could end up affecting the certificate validation of other roots, I don’t have a setup where I could test this.
It’s useful to know those environment variables are used. I have set SSL_CERT_DIR for the server process on my canary host for 2.1 and will report back in the morning with how tonight’s backup goes.
However, this gave me an idea. If this is using the openssl library, I should be able to test the behavior with openssl s_client. And sure enough, with -verify_return_error -CApath /etc/ssl/certs the connection is terminated with a certificate error. I was able to make a successful connection using -CAfile /etc/ssl/certs/ca-certificates.crt though. So I have updated my override.conf for duplicati.service to set SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt and I will see how tonight’s backup goes.
Still no love with SSL_CERT_FILE. Same “2 warnings” showing in the GUI with no warnings in the logs, and no report sent to my tool.
I can try to dig through the docs for libssl to see if there’s something else that can be set that changes the library behavior. Other than that, looking for other suggestions.
I believe the only way to solve it will be adding the functionality to the code to scan the whole chain for the hash specified in send-http-accept-specified-ssl-hash.
I devised a small dotnet utility to print out all the certificate validation status and the chain, if you are up to it, you can test so as to see specially what the properties Certificate validation: and SSL Policy errors evaluate to in your environment and if the chain is properly listed.
The box where I encountered this problem was my first test upgrading to 2.1. It is a Raspberry Pi that I am now questioning the SD card on and I can’t get the .NET SDK installed because I crash the box extracting the zip.
I’m going to upgrade another client. My experience with Duplicati says I will likely encounter this same issue on all of my clients. After confirming the behavior, I’ll run your utility.
