After my recent upgrade of duplicity to version 0.7.07, the software suddenly refused to connect to my webdav storage provider throwing an error message that the SSL cerificate failed to verify. Duplicity seems to ignore the --ssl-no-check-certificate flag. So I decided to fix the bug by directly passing an SSL certificate which duplicity can validate against when connecting to the webdav server.

Problem

When calling duplicity with the --ssl-no-check-certificate flag, the operation fails with an error message saying that the verification of the SSL certificate failed.

This should not happen as the --ssl-no-check-certificate flag should prevent duplicity from any verification at all. In versions prior to 0.7.07, the command worked perfectly.

Solution

As the --ssl-no-check-certificate flag is used to bypass the verification of the webdav server’s identity, this flag basically means that you deliberately switch off security mechanisms which are there to protect you against MiM-attacks. To be honest, I just used this flag because I was too lazy to set up duplicity so that it has a valid certificate it can compare against.

So this bug is a good opportunity to get rid of the --ssl-no-check-certificate shortcut and improve the network security of the server.

Choice of certificate

Unlike major operating systems like Debian or openSUSE, OpenWRT does not ship with a default collection of CA certificates which can be used to verify against when a connection to a remote host is established.

Which certificate do I need?

When we connect to some remote machine by SSL, there are two certificates we have to deal with:

1. The certificate of the website itself and…
2. The certificate of the certification authority (CA) which digitally signed the website certificate and therefore endorses the correct identity of the website’s certificate

We only need a copy of the second certificate. As the website’s certificate would not have been signed by the CA unless its identity was verified, we can be sure that the website’s identity is the one shown on the certificate if we can safely say that the CA signature on the first certificate is correct. (At least so goes the theory. There have been some incidents though which highlight the weakness of this centralized S/MIME architecture)

This leads us to the question how we can establish that the signature on the certificate is correct. The answer is: We need a copy of the CA’s certificate to compare the signature against. For instance, my webdav provider’s certificate has been signed by CERTUM Trusted Network. You can find that out by directing your browser to a https page of the website you want to connect with and check the SSL infos:

 

From where can I get the certificate?

We now need to get hold of that certificate. You have got two possible ways: One is to retrieve the CA’s certificate directly from the CA’s website. Looking at the CA’s website, we find out that the CA itself cannot provide any identity information.

In order to make sure that we really get the original CA certificate and not some faked one, there is a second way to get hold of the CA certificate: We can navigate to the directory with the list of trusted CA certificates on our workstation’s operating system. Under Ubuntu, these certificates reside in /etc/ssl/certs and there is a file called Certum_Root_CA.pem (alternatively we could use Certum_Trusted_Network_CA.pem).

Make a directory called something like /etc/ssl/certs on your OpenWRT router and scp the pem-file from your workstation into that directory.

Adapting the duplicity command

Now that we have the certificate to compare against on our router, the only thing we need to do is to tell duplicity to use it. This is done by simply substituting the previous --ssl-no-check-certificate flag by --ssl-cacert-file=/etc/ssl/certs/Certum_Root_CA.pem in your duplicity commands. After that all should work again – and you can now be sure that your installation has one attack vector less to offer.