Let’s Encrypt est une autorité de certification SSL soutenue par la Linux Foundation et sponsorisée par de nombreux acteurs du web comme Mozilla ou OVH. La documentation ne manque pas sur le client officiel nommé certbot, et pourtant j’ai longtemps été perdu entre les différents moyens de vérification proposés. Voici quelques éléments à connaître avant de faire votre choix.

Pré-requis pour demander un certificat

Un certificat SSL est utile pour sécuriser les transmissions effectuées par un service réseau comme le serveur web, mais aussi FTP, VPN, etc.

A noter que certbot propose trois typologies de méthodes pour obtenir les certificats ou les renouveler :

• Installers (install) : routines qui modifient la configuration d’un service comme Apache ou Nginx.
• Authenticators (certonly) : routines qui vérifient l’adéquation entre le nom de domaine à protéger SSL et l’adresse IP du serveur qui demande le certificat, grâce à un serveur tiers.
• Plugins mixtes (run) : routines qui font les deux.

Pour demander un certificat SSL associé à un domaine pleinement qualifié (FQDN) (exemple : www.domaine.fr) voici les conditions à remplir :

• L’enregistrement DNS www.domaine.fr doit diriger vers le serveur depuis lequel vous émettez la demande. Vous ne pouvez pas demander un certificat depuis un serveur A si le domaine visé pointe vers un serveur B.
• La machine qui demande un certificat doit avoir accès à internet et être accessible sur les ports 80 et 443.
• Vous devez rendre possible l’une des possibilités de vérification proposées par le client Let’s Encrypt.
  • Champ DNS personnalisé (Authenticator). Exemple : certbot certonly -d www.domaine.fr --manual --preferred-challenges dns
  • Modification temporaire de la configuration apache (Installer). Exemple certbot --apache -d www.domaine.fr
  • Modification temporaire de la configuration nginx (Installer). Exemple certbot --nginx -d www.domaine.fr
  • Dépôt d’un fichier dans .well-known sur la racine du site (Authenticator). Exemple certbot certonly --webroot -w /var/www/site -d www.domaine.fr
  • Lancement d’un démon sur le port 80 qui s’occupera de la procédure d’authentification (Authenticator). Exemple certbot certonly --standalone -d www.domaine.fr

La méthode de vérification

Tout dépend de votre contexte mais le choix du mode de vérification n’est pas anodin, et peut engendrer des effets de bord.

Le champ DNS

A mon sens, c’est la méthode de vérification la plus élégante car elle ne fait pas appel à un protocole de « haut niveau » comme HTTP pour opérer la vérification. Tout le monde sur internet utilise DNS (pas forcément HTTP), donc cette méthode est universelle.

Il faudra néanmoins être capable de configurer son serveur DNS, si possible automatiquement grâce à des scripts afin d’obtenir un auto-renouvellement des certificats.

La modification temporaire de la configuration Apache/Nginx

Cette méthode nécessite que certbot soit capable de parser la configuration du serveur web pour la modifier. Or ma configuration Apache est assez compliquée avec php-fpm et différentes règles pour sécuriser mon installation. Chez moi il n’est pas rare d’avoir plusieurs VirtualHost dans /etc/apache2/sites-enabled  ce qui pose problème à certbot.

Avec cette méthode mes demandes de certificat étaient fastidieuses car il fallait que je dé-configure mon serveur apache, lance certbot, et re-configure le tout. Dans ces conditions le renouvellement automatique n’est pas simple non plus : si jamais votre configuration Apache se complexifie avec le temps, vous pouvez avoir de mauvaises surprises.

Le dépôt de fichier dans .well-known

Cette méthode est séduisante car elle ne touche pas à la configuration en place. Elle consiste pour certbot à déposer un fichier temporaire dans le répertoire .well-known à la racine du site, ce qui suffit à vérifier le serveur auprès de Let’s Encrypt.

Dans mon cas de figure le renouvellement n’était pas possible avec cette méthode car certbot cherche à parser ma configuration apache et il s’y casse les dents.

L’inconvénient de cette méthode est qu’on ne peut protéger que des serveurs web accessibles depuis l’extérieur à l’exclusion de tous les serveurs web privés qui implémentent une authentification ou un filtrage IP.

Le démon standalone

Pour finir, cette méthode est ma préférée car elle est simple. Elle utilise le protocole HTTP pour réaliser la vérification, mais c’est un démon « standalone » indépendant. Il ne nécessite même pas qu’Apache ou Nginx soit installé. Par contre il devra prendre le contrôle du port 80 pendant quelques secondes, ce qui impose de fermer tout serveur web pendant ce laps de temps.

Modifier la méthode de vérification après coup

Le client certbot va toujours chercher à réutiliser pour le renouvellement du certificat la méthode qui a été employée de prime abord. Si vous créez un certificat ainsi certbot certonly --standalone -d www.domaine.fr --pre-hook="service apache2 stop" --post-hook="service apache2 start" voici le fichier de configuration qui sera généré dans /etc/letsencrypt/renewal/www.domaine.fr.conf  :

Si vous souhaitez passer à la méthode standalone, il suffit d’éditer ce fichier de configuration.

Supprimer un certificat avant son expiration

Si vous souhaitez désinstaller un certificat SSL créé avec certbot, il faut commencer par le révoquer auprès de l’autorité de certification, pour ensuite supprimer les fichiers qui le composent.

La commande certbot delete  permet de supprimer un certificat parmi la liste proposée. Si votre certificat gère plusieurs domaines, une seule suppression de certificat peut impacter plusieurs domaines.

Le renouvellement automatique

Si vous avez choisi une méthode de vérification qui fonctionne facilement sur votre serveur, le renouvellement est automatique. En effet, certbot installe l’entrée suivante dans le crontab /etc/cron.d/certbot :

L’ordre de renouvellement est lancé ici toutes les douze heures. Personnellement je préfère à 4h du matin car certbot a pour consigne de relancer le serveur web. Le renouvellement auprès de l’autorité de certification n’aura lieu que si le certificat a moins de 30 jours de durée de vie.  On remarque que le lancement de certbot est différé de 0 à 3600 secondes après le déclenchement du cron afin de ne pas saturer les serveurs de Let’s Encrypt.