Renouvelez vos certificats par automatisation ou pas du tout

L'affirmation

Un certificat TLS qu'un humain doit penser à renouveler finira, tôt ou tard, par expirer une fin de semaine et mettre votre site hors ligne — et l'industrie retire activement la marge d'erreur. La durée de vie des certificats se réduit vers 47 jours d'ici 2029, ce qui rend le renouvellement manuel non seulement risqué mais impraticable : personne n'exécutera un processus manuel huit fois par an sans en manquer un. Automatisez le renouvellement, surveillez l'automatisation, et toute la catégorie des pannes d'expiration de certificat disparaît.

Pourquoi cela devient plus urgent, pas moins

La durée de validité maximale des certificats TLS publics baisse depuis des années, et le calendrier pointe désormais nettement vers le bas : des 398 jours actuels vers 200, puis 100, puis 47 jours d'ici 2029. Le raisonnement est solide — des durées plus courtes limitent les dégâts d'une clé compromise et forcent l'automatisation qui rend le système plus robuste. Mais la conséquence pour vous est directe : un certificat que vous renouvelez à la main aujourd'hui, quatre fois par décennie, deviendrait un certificat à renouveler huit fois par an, et un processus manuel à cette fréquence est une certitude d'échec, pas une possibilité.

La configuration automatisée

Le protocole ACME émet et renouvelle les certificats sans intervention humaine. Un client prouve le contrôle du domaine, reçoit le certificat, et recommence avant l'expiration. Avec certbot :

certbot certonly --nginx -d exemple.ca -d www.exemple.ca

# certbot installe une minuterie systemd qui renouvelle automatiquement ;
# confirmez qu'elle existe et voyez sa prochaine execution :
systemctl list-timers | grep certbot

Le renouvellement tourne deux fois par jour et ne fait rien tant qu'un certificat n'est pas à moins de 30 jours de l'expiration, moment où il renouvelle et recharge le serveur Web. Une fois cela en place, le certificat se renouvelle indéfiniment et vous n'y pensez plus — ce qui est le but, et aussi le piège, car un système automatisé silencieux qui casse est exactement aussi invisible qu'aucun système.

Préférez la validation par DNS pour tout cas non trivial

Il y a deux façons de prouver le contrôle du domaine, et le choix compte plus qu'il n'y paraît. La validation par HTTP place un fichier sur votre serveur Web ; simple, mais elle casse pour les certificats génériques et pour tout hôte injoignable sur le port 80 depuis l'internet public. La validation par DNS place un enregistrement temporaire dans votre zone ; un peu plus de configuration, mais elle gère les certificats génériques, fonctionne pour les hôtes internes, et ne dépend pas de la joignabilité de votre serveur Web au moment du renouvellement.

certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/dns.ini \
  -d '*.exemple.ca' -d exemple.ca

Pour un site public unique, la validation par HTTP convient. Pour tout ce qui comporte un certificat générique, plusieurs hôtes ou des services internes, la validation par DNS est le choix par défaut plus robuste, et l'adopter tôt évite une migration plus tard.

La règle qui rend l'automatisation digne de confiance : surveillez-la à part

Voici la défaillance qui piège les équipes ayant bien automatisé : l'automatisation de renouvellement elle-même casse — un identifiant d'API expire, un fournisseur DNS change d'interface, une permission est révoquée — et parce que le système était silencieux en fonctionnant, son silence en panne ne lève aucune alarme. Le certificat expire alors exactement comme sans automatisation, et l'équipe est surprise parce qu'elle croyait le problème réglé.

La défense est une vérification indépendante qui ignore comment le certificat est renouvelé. Elle se connecte de l'extérieur et lit la date d'expiration réelle sur le certificat en service :

echo | openssl s_client -servername exemple.ca -connect exemple.ca:443 2>/dev/null \
  | openssl x509 -noout -enddate

Exécutez cela quotidiennement depuis un hôte qui n'est pas le serveur Web, analysez la date, et alertez si l'expiration est à moins de 14 jours. Cette vérification réussit quel que soit le client ou la méthode ayant émis le certificat, et elle échoue que la cause soit une automatisation cassée, un certificat manuel oublié, ou un renouvellement qui a tourné sans recharger le serveur. C'est le filet qui transforme « on l'a automatisé » en « on sait que ça fonctionne ».

Le rechargement que personne ne teste

Une défaillance subtile et courante : le certificat se renouvelle correctement sur le disque, mais le serveur Web continue de servir l'ancien en mémoire parce que rien ne l'a rechargé. Le nouveau certificat est là, dans le système de fichiers, valide, et le site présente toujours l'expiré aux visiteurs. Assurez-vous que le crochet de renouvellement recharge le serveur, et testez-le — la surveillance externe ci-dessus attrape ce cas aussi, car elle lit ce qui est réellement servi, pas ce qui repose dans un fichier.

certbot renew --deploy-hook "systemctl reload nginx"

Quoi faire cette semaine

Confirmez trois choses, dans l'ordre. D'abord, que chaque certificat public que vous exploitez se renouvelle automatiquement — trouvez ceux qui ne le font pas et migrez-les vers un client ACME maintenant, avant que le calendrier des durées courtes ne rende cela urgent. Ensuite, qu'une vérification externe indépendante lit vos dates d'expiration en service et alerte avec une vraie marge. Enfin, que le renouvellement recharge le processus en service. Un site dont les certificats se renouvellent automatiquement, dont le renouvellement est surveillé par quelque chose qui ne lui fait pas confiance, et dont le serveur adopte réellement le nouveau certificat a supprimé l'une des pannes les plus courantes et les plus évitables qui soient — et l'a fait d'une manière qui continue de fonctionner à mesure que les durées de vie se réduisent.