« On renouvelle tous les certificats à la main, ça prend cinq minutes par site » : cette phrase, entendue sur plus d’un parc serveur, résume un choix qui fonctionne parfaitement bien jusqu’au jour où il ne fonctionne plus. Le renouvellement manuel d’un certificat TLS n’est jamais le problème en soi ; c’est sa dépendance totale à la mémoire d’une personne qui finit, statistiquement, par se retourner contre l’équipe.
Cette pratique reste étonnamment répandue sur des parcs de taille modeste, où l’administrateur historique connaît chaque échéance par cœur et où un tableur, parfois même une simple habitude, sert de calendrier de suivi. Le jour où cette personne est en congé, change de poste, ou simplement oublie une échéance noyée parmi d’autres priorités, le certificat expire, et le site devient inaccessible avec une alerte de sécurité affichée à chaque visiteur.
Ce que le renouvellement manuel demande, en apparence
Sur un certificat Let’s Encrypt, valable quatre-vingt-dix jours, le renouvellement manuel consiste à relancer une commande, vérifier que le nouveau certificat est bien pris en compte par le serveur web, puis redémarrer le service concerné. Pour un parc de quelques sites, cette tâche paraît effectivement rapide et sans risque particulier, ce qui explique pourquoi elle reste non automatisée sur tant d’infrastructures.
certbot certonly --webroot -w /var/www/monsite -d monsite.fr
systemctl reload nginx
Le problème n’est jamais la commande elle-même, mais la fiabilité du déclenchement de cette commande au bon moment, tous les quatre-vingt-dix jours, sans exception et sans oubli, pour chaque site du parc, potentiellement pendant des années.
Le jour où ça casse : le scénario type
Le scénario le plus fréquent ressemble à ceci : la personne responsable du renouvellement change de poste, part en congé prolongé, ou l’équipe grandit et personne ne reprend explicitement cette responsabilité. Le calendrier informel qui fonctionnait tant que la mémoire d’une seule personne suffisait s’effondre silencieusement, sans qu’aucune alerte ne prévienne qui que ce soit avant l’expiration effective.
Le certificat expire alors un jour ordinaire, sans lien avec une action particulière côté serveur. Les visiteurs voient s’afficher un avertissement de sécurité bloquant dans leur navigateur, et le trafic chute brutalement le temps que quelqu’un remarque le problème, souvent signalé par un client plutôt que détecté en interne.
Ce que Certbot automatise réellement
Certbot embarque nativement un mécanisme de renouvellement automatique, installé par défaut sous forme de tâche cron ou de timer systemd selon la distribution, qui vérifie deux fois par jour si un certificat approche de son échéance et le renouvelle silencieusement si nécessaire, sans intervention humaine :
systemctl list-timers | grep certbot
certbot renew --dry-run
La commande certbot renew --dry-run simule le renouvellement sans le déclencher réellement, ce qui permet de vérifier que l’automatisation fonctionnerait correctement le jour venu, sans attendre l’échéance réelle pour le découvrir.
Pourquoi le coût de mise en place reste minime face au risque
Mettre en place cette automatisation demande, une fois pour toutes, de vérifier que le timer ou le cron de Certbot est bien actif, et d’ajouter un hook de redémarrage du service concerné après chaque renouvellement effectif, via l’option --deploy-hook :
certbot renew --deploy-hook "systemctl reload nginx"
Ce travail se fait en quelques minutes, une seule fois par serveur, et élimine ensuite définitivement la dépendance à la mémoire humaine pour cette tâche récurrente. Comparé au coût d’un site inaccessible pendant plusieurs heures, le temps investi dans cette automatisation est dérisoire.
- Le renouvellement manuel fonctionne tant qu’une personne s’en souvient
- Certbot automatise la vérification et le renouvellement deux fois par jour
- Un hook de redémarrage garantit que le service prend en compte le nouveau certificat
- Le coût de mise en place est minime comparé au coût d’un oubli réel
Ce qui reste hors de ce constat
Ce constat ne tranche volontairement pas la question du choix de l’autorité de certification à utiliser, Let’s Encrypt ou une autre, ni les critères qui pourraient orienter ce choix selon les besoins spécifiques d’un projet. Il porte uniquement sur la mécanique du renouvellement une fois l’autorité choisie.
Sur les parcs que nous avons repris après un incident de ce type, la première action a toujours été la même : automatiser le renouvellement avant même de corriger quoi que ce soit d’autre, tant le risque de récidive était immédiat.
En résumé
Le renouvellement manuel d’un certificat TLS fonctionne parfaitement jusqu’au jour où la mémoire humaine qui le soutient fait défaut, avec un coût d’incident sans commune mesure avec le temps qu’aurait demandé une automatisation fiable via Certbot. Vérifier que le timer de renouvellement automatique est actif, et qu’un hook redémarre correctement le service concerné, suffit à éliminer ce risque pour de bon.
