Triggered by the quarterly reneval of my SSL certificates, I thought I’d sum up some information about the way I handle them.

First information is that I have switched to using let’s encrypt for all my SSL certificates (https, smtps) back in 2016.

Let’s encrypt itself provides a script to get the certificates, acme.sh. This script has two disadvantages, why I don’t use it :

• it runs with root permissions on the host, modifying the SSL, mail server and webserver configuration as it wants
• it re-generates the certificates every 3 months

While the first point is a matter of personal taste (or paranoia), the second one is a nightmare when using DKIM ! Each time the certificate is changed, it has to be uploaded to the DNS system and signed by the DNS provider. When using let’s encrypt certifcates, this would be every 3 months !

But actually this is not necessary at all ! The acme.sh is going the easiest way, but the ACME protocol doesn’t require certificates to be re-generated every 3 months. The only thing that expires every 3 months is the signature of the SSL certificate by the let’s encrypt certification authority (CA). Son in practice, it is possible to use the same certificate over and over, just submitting it for re-signing every 3 months. This is what I’m doing since 2016 ! Actually my SSL certificate was even created back in 2014 !

The initial generation of a certificate can be as easy as issuing following command :

1

openssl genrsa -out certs/$domain.key 4096

Talking about the (re)signing process… I’m using the dehydrated ACME client, which is a shell script. It only requires a text file that lists the domains to be validated - multiple domains can be given per line, they’ll end up as “Certificate Subject Alternaive Names” in the SSL certificate and have the purpose of allowing the usage of a single SSL certificate for multiple (sub)domains. For instance

1

joel-hatsch.net www.joel-hatsch.net techblog.joel-hatsch.net mail.joel-hatsch.net

The acme v1 process validates each domain by veryfing that a specifc file with a specific content (“challenge”) can be accessed. The key point is that this file must not be provided by the domain to be validated. Rather, it can be provided by a different domain if a corresponding redirect is implemented on the webserver.

What does that mean ? Actually that the challenges for all domains I’m managing can be server by my main domain, www.joel-hatsch.net. Also there’s no restriction on the IP address of the server. This means even domains hosted on different servers can be validated by providing the challenge on www.joel-hatsch.net. I’m not sure if this is really an issue, as it still requires an attacker to have control over the webserver in order to implement the redirection.

One nice feature of dehydrated is that the user can provide an own script to upload the files to a distant server (“HOOK= statement in the config file). My script (sync_challenge.sh) looks as follows :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

#!/bin/zsh

# call : ${HOOK} "clean_challenge" '' "${challenge_token}" "${keyauth}"

action=$1
aa=$2
token=$3
auth=$4

# challenges are in the .acme-challenge directory
rsync -av -e "ssh" --rsync-path="sudo rsync" .acme-challenge/ root@www.joel-hatsch.net:/var/www/joel-hatsch.net/httpdocs/.well-known/acme-challenge/