Comment fiabiliser le renouvellement d'un certificat Let's Encrypt ?

Un certificat expiré rend un site inaccessible avec un message qui alarme le visiteur bien plus qu'une page d'erreur ordinaire, et il tombe toujours un dimanche. Le renouvellement automatique d'un certificat Let's Encrypt est censé rendre cette situation impossible, et il y parvient sur la grande majorité des installations. Les échecs, quand ils surviennent, ont presque toujours la même origine : une modification faite sur le site des mois plus tôt, une redirection ajoutée, un dossier protégé, un serveur qui n'a pas été rechargé. Comprendre le mécanisme de validation suffit à identifier ces causes en quelques minutes, et à mettre en place la surveillance qui évite de découvrir le problème par un appel de client un dimanche matin.

Comprendre le mécanisme

Le protocole repose sur une idée simple : prouver automatiquement qu'on contrôle bien le domaine pour lequel on demande un certificat. Tout le reste en découle, y compris la nature des pannes que l'on rencontre. Ces notions font partie du socle d'exploitation que nous rappelons dans la rubrique création de site Internet pour les projets hébergés en propre.

Une durée de vie courte, par conception

Les certificats délivrés ont une validité de quatre vingt dix jours, contre un an pour les certificats commerciaux traditionnels. Ce choix n'est pas une limitation mais une décision de sécurité : une clé compromise reste exploitable moins longtemps, et surtout une durée courte oblige à automatiser le renouvellement, ce qui supprime l'erreur humaine que constituait le renouvellement manuel annuel. L'organisme a par ailleurs annoncé la mise à disposition de certificats de six jours, poussant encore plus loin cette logique d'automatisation obligatoire.

Le renouvellement à trente jours

Les clients de renouvellement tentent l'opération lorsqu'il reste trente jours de validité, et réessaient ensuite régulièrement. Cette marge est généreuse et volontaire : elle laisse un mois pour qu'un échec soit détecté et corrigé avant toute conséquence visible. C'est aussi ce qui explique qu'un problème puisse rester invisible pendant quatre semaines avant de provoquer une panne, et pourquoi la surveillance doit porter sur les échecs de renouvellement autant que sur la date d'expiration.

La validation par fichier

La méthode la plus répandue consiste à déposer un fichier dans un dossier précis du site, sous un chemin réservé, puis à laisser l'autorité venir le lire par une requête ordinaire. Elle est simple, ne demande aucun accès particulier, et elle est aussi la plus fragile, puisqu'elle dépend du bon fonctionnement du serveur web et de la façon dont il traite ce chemin. La quasi totalité des échecs de renouvellement que nous rencontrons portent sur cette seule étape.

La validation par enregistrement de nom

La seconde méthode consiste à publier une valeur dans la configuration du nom de domaine, que l'autorité vient vérifier. Elle est indépendante du serveur web, ce qui la rend beaucoup plus robuste, et elle est la seule possible pour obtenir un certificat couvrant tous les sous domaines d'un seul coup. Elle demande en contrepartie que le fournisseur du nom de domaine expose une interface de programmation, et que le client de renouvellement sache s'en servir, ce qui est le cas pour la plupart des hébergeurs et des bureaux d'enregistrement courants en France.

Ce que le certificat ne dit pas

Un certificat de ce type atteste que le demandeur contrôle le domaine, rien de plus. Il ne dit rien de l'identité juridique de l'entreprise, contrairement aux certificats à validation étendue, dont l'affichage privilégié a d'ailleurs disparu des navigateurs. Cette distinction, qui alimentait autrefois des argumentaires commerciaux, n'a plus aucune portée pratique : le cadenas affiché est rigoureusement le même, et le chiffrement mis en oeuvre est identique.

Le client de renouvellement et sa tâche planifiée

Le composant qui exécute le renouvellement s'installe une fois et travaille ensuite tout seul, ce qui explique qu'on l'oublie complètement. Il pose lui même une tâche planifiée, généralement deux fois par jour à une heure décalée pour éviter que tous les serveurs du monde ne sollicitent l'autorité au même instant. Trois points méritent une vérification à l'installation, et une seule fois. Le premier est l'utilisateur sous lequel la tâche s'exécute, qui doit avoir le droit d'écrire dans le dossier des certificats et de recharger le serveur, sans être pour autant administrateur complet de la machine. Le deuxième est la survie de cette tâche à une mise à jour du système, plusieurs distributions ayant changé de mécanisme de planification au fil des versions. Le troisième est l'adresse électronique déclarée lors de la première demande : c'est à elle que l'autorité écrit lorsqu'un certificat approche de son expiration sans avoir été renouvelé, et une adresse d'un prestataire parti depuis trois ans rend ce filet parfaitement inopérant.

Ce qui fait échouer un renouvellement

Les causes sont peu nombreuses et se diagnostiquent vite quand on les connaît. Elles relèvent presque toutes de modifications faites sur le site sans penser à cette mécanique, ce qui rejoint les précautions décrites dans notre article sur ce qu'il faut savoir quand un plugin modifie le fichier .htaccess.

La redirection qui capture tout

C'est la cause numéro un. Une règle qui redirige l'ensemble du trafic non chiffré vers sa version chiffrée capture aussi la requête de validation, qui arrive nécessairement en clair. Le contrôle échoue alors sans message explicite. La correction consiste à exclure explicitement le chemin de validation de cette redirection, exception qui tient en une ligne et qui doit figurer par principe sur toute configuration redirigeant vers le protocole sécurisé, y compris quand aucun certificat n'est encore en place.

Le contrôleur frontal qui intercepte

Sur un site où toutes les adresses passent par un point d'entrée unique, la requête de validation est traitée par l'application, qui répond une page d'erreur au lieu du fichier attendu. Le symptôme est identique au précédent et la correction similaire : le chemin réservé doit être servi comme un fichier statique, avant toute réécriture. C'est le même mécanisme qui protège les médias et les ressources, il suffit d'y ajouter ce chemin réservé au même titre que les images et les feuilles de style.

Le site protégé par un mot de passe

Une préproduction protégée par une authentification du serveur bloque la lecture du fichier de validation, puisque l'autorité ne dispose d'aucun identifiant. La protection doit donc laisser passer le chemin réservé, exception à écrire explicitement. Le cas se présente aussi sur les sites en maintenance prolongée, et il est particulièrement pénible parce que le certificat expire pendant que le site est censé être hors ligne, si bien que la remise en service commence par un incident.

Le serveur qui n'est jamais rechargé

Le certificat est renouvelé sur le disque, mais le serveur web continue de servir l'ancien tant qu'il n'a pas été rechargé. La configuration doit donc prévoir un rechargement après renouvellement, ce que les clients modernes gèrent par un mécanisme de tâche postérieure. Ce cas est particulièrement traître : tout paraît fonctionner, les journaux du client indiquent un succès, et le site sert malgré tout un certificat expiré. Le contrôle se fait donc obligatoirement depuis l'extérieur, en interrogeant le serveur comme le ferait un visiteur, jamais en lisant la date inscrite dans le fichier posé sur le disque.

Les limites de fréquence atteintes

L'autorité applique des limites sur le nombre de certificats délivrés par domaine et par semaine, et sur le nombre d'échecs consécutifs. Un client mal configuré qui réessaie en boucle finit par se voir refuser toute nouvelle demande pendant plusieurs jours, ce qui transforme un problème mineur en panne réelle. La règle est donc de ne jamais boucler sur un échec, et d'utiliser systématiquement l'environnement de test proposé par l'autorité pendant les phases de mise au point, qui ne compte dans aucune limite.

Mettre en place une configuration solide

Quelques décisions prises à l'installation évitent la quasi totalité des incidents ultérieurs, et elles ne coûtent presque rien au moment de la mise en place.

Choisir la bonne méthode de validation

Pour un site unique sur un serveur classique, la validation par fichier convient parfaitement, à condition d'écrire les exceptions décrites plus haut. Dès qu'il s'agit de couvrir plusieurs sous domaines, ou qu'un service de répartition de charge se place devant le serveur, la validation par enregistrement de nom devient nettement préférable, parce qu'elle ne dépend d'aucune configuration du site. Ce choix se fait une fois pour toutes et conditionne la robustesse de l'ensemble du dispositif pour les années suivantes.

Lister tous les noms couverts

Un certificat couvre les noms qu'on lui a demandés, et il est fréquent d'en oublier un : la version avec et sans préfixe, un sous domaine de préproduction, un ancien domaine encore redirigé. Chaque nom oublié produit une alerte de sécurité chez les visiteurs qui l'utilisent. La liste doit être établie explicitement, écrite dans la configuration du client, et revue à chaque ajout de sous domaine, sans quoi le nouveau service fonctionnera parfaitement en interne et déclenchera une alerte de sécurité chez le premier visiteur extérieur.

Scripter le rechargement

Le rechargement du serveur après renouvellement doit être déclaré dans la configuration du client plutôt que dans une tâche séparée, afin qu'il ne s'exécute que lorsqu'un certificat a réellement changé. Sur une machine servant plusieurs services, base de données, serveur de courriel, service de messagerie interne, tous doivent être rechargés, ce que l'on oublie à peu près systématiquement pour les services autres que le serveur web, jusqu'au jour où un client de messagerie refuse la connexion.

Tester la chaîne complète

La recette d'une installation consiste à forcer un renouvellement, puis à vérifier depuis l'extérieur que le certificat servi porte bien la nouvelle date. Cette manipulation prend deux minutes et vaut à elle seule toutes les lectures de journaux, puisqu'elle teste ce que voit réellement un visiteur. Elle doit être refaite après tout changement d'hébergement, de configuration de serveur ou de fournisseur de nom de domaine, trois événements qui cassent régulièrement le dispositif sans que personne ne fasse le lien sur le moment.

Documenter l'installation

Une note de quelques lignes doit indiquer quel client est installé, sous quel utilisateur il tourne, quelle méthode de validation il emploie, quels noms sont couverts et quelle commande recharger. Sans elle, un incident survenant deux ans plus tard commence par une demi journée d'archéologie, et la personne qui intervient n'est à peu près jamais celle qui a procédé à l'installation.

La chaîne de certification et les vieux clients

Un dernier point cause des incidents difficiles à comprendre parce qu'ils n'affectent qu'une partie des visiteurs. Le serveur ne sert pas seulement le certificat du site mais aussi la chaîne qui le relie à une autorité racine connue, et cette chaîne doit être complète et servie dans le bon ordre. Une configuration incomplète fonctionne parfaitement dans les navigateurs récents, qui savent compléter la chaîne d'eux mêmes, et échoue sur les appareils anciens, sur certains clients de messagerie et sur les outils en ligne de commande utilisés par les intégrations. Le symptôme typique est un site qui marche pour tout le monde mais dont une synchronisation automatique refuse obstinément de se connecter. La vérification se fait avec un outil d'analyse en ligne qui teste la chaîne complète, et elle mérite d'être refaite après chaque changement d'autorité intermédiaire, événement rare mais qui s'est déjà produit.

Surveiller et prévoir le pire

Aucune configuration ne dispense d'une surveillance, ne serait ce que parce que les causes d'échec viennent de l'extérieur du dispositif.

Surveiller depuis l'extérieur

Le seul contrôle qui vaut consiste à interroger le port sécurisé depuis une machine tierce et à lire la date d'expiration du certificat réellement servi. Un contrôle quotidien suffit largement, avec une première alerte à trente jours puis une seconde à sept jours, et il doit porter sur chaque nom couvert par le certificat plutôt que sur le seul domaine principal, un sous domaine oublié étant précisément le cas qui échappe à tout le monde. Cette surveillance rejoint celle décrite dans notre article sur la manière de surveiller un WordPress en production.

Surveiller aussi les échecs

Une alerte fondée uniquement sur la date d'expiration prévient tard, quand plusieurs tentatives ont déjà échoué. Il est bien plus utile de remonter directement l'échec du client de renouvellement, qui écrit ses résultats dans un journal dédié et peut déclencher une notification en cas d'échec. Un échec isolé peut être parfaitement passager, un incident réseau suffit à l'expliquer, mais un second échec consécutif mérite une intervention immédiate, sans attendre l'approche de la date limite, la marge de trente jours ne servant à rien si personne ne l'utilise.

Connaître la procédure de secours

Le jour où le renouvellement automatique échoue et que le certificat expire, la manœuvre consiste à corriger la cause puis à forcer un renouvellement manuel, ce qui prend quelques minutes une fois la cause identifiée. Cette procédure, avec les commandes exactes et l'emplacement des fichiers, doit être écrite quelque part d'accessible sans le site, puisque celui ci sera précisément inaccessible. C'est typiquement le genre de note que l'on regrette de ne pas avoir écrite exactement au moment où l'on en aurait le plus besoin.

Anticiper les changements d'infrastructure

Un changement d'hébergeur, l'ajout d'un service de distribution de contenus ou la mise en place d'un pare feu applicatif modifient le chemin emprunté par la requête de validation, et cassent le renouvellement sans le moindre signe immédiat. La règle consiste à inclure la vérification du renouvellement dans la recette de toute intervention sur l'infrastructure, au même titre que le contrôle des adresses. Le décalage entre le changement et la panne, qui peut atteindre trois mois, rend le lien impossible à établir sans cette discipline, personne ne pensant à une intervention vieille de trois mois.

Les certificats gérés par l'hébergeur

Sur un hébergement mutualisé, tout ce mécanisme est pris en charge par le prestataire, et il n'y a rien à configurer. Cela ne dispense en rien de la surveillance : les incidents existent aussi de ce côté, souvent lors d'un changement de formule ou d'une modification de la configuration du nom de domaine. Le contrôle externe reste donc pertinent, et il coûte exactement la même chose que sur un serveur géré en propre, pour un bénéfice identique. La différence tient seulement à la nature de la réaction : au lieu de corriger soi même, il faut ouvrir un ticket et fournir la preuve du problème, ce qu'un relevé daté du certificat servi rend nettement plus rapide.