Renouvellement Let's Encrypt : les trois pannes classiques

Le renouvellement automatique de certificat a une personnalité bien à lui : il fonctionne impeccablement pendant des mois, puis s'arrête, et ne le dit à personne. La commande tourne toujours à l'heure. Elle sort simplement en erreur, dans un fichier de log que personne n'ouvre. Voici les trois façons dont elle casse réellement, et la seule vérification qui les attrape toutes les trois.

Les trois pannes, en un tableau

La troisième ligne est celle qui coûte le plus cher, précisément parce que le journal a l'air parfait. Une supervision qui lit le journal de renouvellement déclare donc que tout va bien pendant que vos visiteurs voient un écran rouge.

1. Le défi de validation n'atteint plus votre serveur

Pour confirmer que vous contrôlez le domaine, l'autorité de certification demande un fichier sous /.well-known/acme-challenge/… sur votre site. Votre serveur doit le servir, en HTTP simple, sans interférence.

Ce qui casse cela, des mois après la mise en place :

• Une redirection globale vers HTTPS ou vers un nouveau domaine, ajoutée pour d'excellentes raisons, et qui attrape aussi le chemin du défi.
• Une règle de pare-feu ou de WAF qui se met à filtrer les chemins inconnus, ou qui bloque les adresses depuis lesquelles la validation arrive.
• Une route attrape-tout de framework qui transforme chaque URL inconnue en page 404, y compris le fichier de défi, qui renvoie désormais un 404 dans une jolie mise en page.
• Une protection anti-robots installée devant le site, qui présente une page d'attente à tout client qui n'exécute pas de JavaScript.

La commande de renouvellement n'a pas changé. Son environnement, si. C'est ce qui rend cette panne difficile à imputer : personne n'a touché au certificat, et pourtant il ne se renouvelle plus.

Le test tient en une ligne, depuis n'importe quelle machine :

mkdir -p /var/www/html/.well-known/acme-challenge && echo ok > /var/www/html/.well-known/acme-challenge/test
curl -sI http://exemple.fr/.well-known/acme-challenge/test | head -n 1

La réponse attendue est 200. Une 301 vers HTTPS est déjà un problème dans certaines configurations, et un 403 ou un 404 en est toujours un.

2. Le DNS a bougé

Si vous renouvelez un certificat joker, la validation passe par un enregistrement DNS au lieu d'un fichier. Cela suppose un jeton d'API chez votre fournisseur DNS, posé dans un fichier de configuration, et qui expire ou se fait révoquer en silence le jour où quelqu'un fait tourner les identifiants.

Trois variantes de la même histoire :

• Le jeton a été révoqué lors d'un ménage de sécurité, six mois plus tôt.
• Le domaine a été transféré chez un autre bureau d'enregistrement, et personne n'a pensé à en informer le script.
• Les serveurs de noms ont changé, la zone est désormais gérée ailleurs, et le script écrit consciencieusement son enregistrement dans une zone que plus personne ne consulte.

Dans les trois cas, l'erreur est explicite dans le journal. Encore faut-il que quelqu'un l'ouvre, et c'est tout le problème.

3. Le renouvellement a réussi, pas le déploiement

C'est la version cruelle. Le nouveau certificat est sur le disque, daté d'aujourd'hui, parfaitement valide. Votre serveur web présente toujours l'ancien, parce qu'il n'a pas été rechargé depuis son démarrage.

Rien dans le journal de renouvellement n'a l'air anormal. Le fichier est bien là. Et vos visiteurs reçoivent quand même l'avertissement de sécurité en plein écran.

La cause est presque toujours un crochet de rechargement absent ou silencieux :

# Le rechargement doit faire partie du renouvellement, pas d'un geste manuel
--deploy-hook "systemctl reload nginx"

Deux pièges à connaître. Un crochet qui échoue ne fait pas échouer le renouvellement : il laisse un message dans le journal et rend la main. Et un service qui a besoin d'un redémarrage complet, plutôt que d'un rechargement, ne reprend pas le nouveau fichier ; c'est fréquent sur les configurations qui terminent le TLS ailleurs que dans le serveur web, derrière un proxy ou un répartiteur de charge, où le certificat doit être poussé à deux endroits.

La quatrième panne, plus rare et plus déroutante

Les trois précédentes viennent de votre installation. Celle-ci vient d'ailleurs, et elle déroute parce que la commande est correcte et que le serveur est irréprochable.

Le quota a été atteint. Les autorités de certification limitent le nombre de certificats émis pour un même domaine sur une période donnée. On y arrive rarement en fonctionnement normal, et très facilement en boucle de débogage : dix tentatives de réémission dans l'après-midi, et vous voilà bloqué pour une semaine avec un certificat expiré en production. C'est la raison d'être de l'essai à blanc, qui ne consomme rien.

La clé de compte a disparu. Une réinstallation du serveur, une restauration partielle, un conteneur reconstruit sans son volume : le client ne retrouve plus le compte qui possédait les certificats, et repart de zéro sans le dire clairement.

Le domaine ne résout plus vers vous. Un enregistrement modifié, une migration en cours, un basculement mal terminé. La validation échoue parce qu'elle atterrit sur une autre machine, ce qui est exact et n'a rien à voir avec le certificat.

Diagnostiquer en trois commandes

certbot renew --dry-run                 # rejoue tout le renouvellement sans consommer de quota
curl -sI http://exemple.fr/.well-known/acme-challenge/test   # le défi passe-t-il
echo | openssl s_client -connect exemple.fr:443 2>/dev/null | openssl x509 -noout -dates

La première attrape les pannes 1 et 2. La troisième attrape la panne 3, et elle est la seule à dire ce que le public reçoit réellement.

Et si vous voulez seulement savoir ce que le public reçoit en ce moment, sans ouvrir de terminal, la page qui lit un certificat répond à cette question précise en une adresse.

Ce qu'il ne faut pas faire pendant la panne

Ne réémettez pas en boucle : c'est ainsi qu'un problème réparable devient un problème d'une semaine. Ne coupez pas HTTPS pour « remettre le site en ligne » : tous les liens du web qui pointent vers vos adresses en https:// casseraient, et les navigateurs mémorisent longtemps cette préférence. Et n'installez pas un certificat autosigné en dépannage : il produit exactement la même page rouge, avec les mêmes conséquences, plus un second problème à défaire ensuite.

La vérification qui attrape les trois

Chacune de ces pannes est invisible depuis l'intérieur et évidente depuis l'extérieur. Alors regardez depuis l'extérieur : ouvrez une connexion TLS vers votre propre nom d'hôte et lisez la date d'expiration du certificat réellement servi.

Cette seule mesure couvre d'un coup un défi échoué, un problème DNS et un rechargement manquant, parce que les trois finissent au même endroit : un vieux certificat toujours présenté au public. Elle a aussi le mérite de ne rien supposer de votre installation, ce qui la rend valable après un changement d'hébergeur ou de pile technique.

Alertez à trente jours, sept jours et un jour. Trente laissent la place pour déboguer calmement ; un attrape le rechargement qui n'a jamais eu lieu. Une vérification quotidienne suffit largement, et c'est un cas où augmenter la fréquence n'apporte rien : une date d'expiration ne change pas d'une heure à l'autre.

Deux habitudes qui valent la peine

Renouveler avec de la marge. À soixante jours sur un certificat de quatre-vingt-dix, un échec vous laisse un mois plutôt qu'un après-midi. C'est le réglage par défaut de la plupart des clients, et c'est une des rares valeurs par défaut qu'il ne faut surtout pas toucher.

Tester le renouvellement, pas seulement le certificat. L'essai à blanc existe dans presque tous les clients. Le lancer une fois par mois transforme une panne silencieuse en panne connue, des mois avant qu'elle ne compte. Et parce que personne d'autre ne vous préviendra, c'est votre seule alerte avancée.

Quand ça a déjà expiré

Ne cherchez pas la cause d'abord. Renouvelez et rechargez, remettez le site en état, et faites l'enquête ensuite : c'est le même ordre que les quinze premières minutes d'un incident, pour la même raison, à savoir qu'un site bloqué coûte quelque chose à chaque minute pendant que vous comprenez.

Rien de tout cela ne change votre référencement, au passage : HTTPS pèse beaucoup moins pour les moteurs que la panique ne le suggère. Cela compte pour la personne qui ne peut pas ouvrir votre site.