Certificats SSL : automatiser le renouvellement avec Certbot

L'époque des certificats SSL achetés à prix d'or pour trois ans et renouvelés manuellement à la sueur de son front est révolue. Avec l'avènement de Let's Encrypt et du protocole ACME, le chiffrement HTTPS est devenu gratuit, universel et automatisable. Toutefois, la durée de vie courte des certificats Let's Encrypt (90 jours) impose une rigueur absolue : le moindre grain de sable dans le processus de renouvellement automatique peut rendre votre site ou votre API inaccessible du jour au lendemain, affichant un écran d'avertissement rouge dissuasif à tous vos visiteurs.

Comprendre le fonctionnement de Certbot et des challenges ACME

Certbot est le client de référence pour dialoguer avec Let's Encrypt. Lorsqu'il demande ou renouvelle un certificat, il doit prouver que vous contrôlez bien le nom de domaine concerné. Le challenge le plus courant est `HTTP-01` : Certbot dépose un fichier temporaire dans `/.well-known/acme-challenge/` et les serveurs de Let's Encrypt viennent le lire sur le port 80. Si votre serveur est derrière un pare-feu restrictif ou si vous avez besoin d'un certificat wildcard (`*.domaine.fr`), vous devrez utiliser le challenge `DNS-01`, qui consiste à créer automatiquement un enregistrement TXT via l'API de votre fournisseur DNS (Cloudflare, OVH, Gandi).

# Tester le renouvellement sans modifier les certificats en production
sudo certbot renew --dry-run

# Vérifier l'état du timer systemd dédié au renouvellement
sudo systemctl list-timers | grep certbot

Ne jamais oublier le rechargement du serveur web

Une erreur classique consiste à renouveler le certificat sur le disque sans prévenir Nginx, Apache ou HAProxy. Tant que le service web n'est pas rechargé, il continue de servir l'ancien certificat expiré qu'il garde en mémoire. Heureusement, Certbot permet de définir des `--deploy-hook` : des commandes exécutées uniquement lorsqu'un renouvellement a réellement réussi. C'est l'endroit idéal pour lancer un `systemctl reload nginx` sans couper les connexions actives.

Un renouvellement automatique qui n'a jamais été testé avec --dry-run est une panne programmée à 90 jours.

Superviser l'expiration en double sécurité

Même avec un timer systemd fonctionnel, ne faites jamais une confiance aveugle à l'automatisation. Ajoutez systématiquement une sonde de monitoring externe qui vérifie la date d'expiration du certificat présenté par votre serveur et déclenche une alerte dès que la validité passe sous la barre des 20 jours. Cela vous laisse une marge confortable pour diagnostiquer un blocage de port 80 ou une clé API DNS expirée avant l'incident.