Certificats TLS : l'expiration, première cause de site inaccessible
Un certificat TLS porte une date de début et une date de fin, et un navigateur refuse la connexion dès que l'horloge les dépasse. C'est la panne la plus banale d'un parc de sites, et la plus évitable : elle ne dépend ni du trafic, ni du matériel, ni d'une attaque, seulement d'un renouvellement qui n'a pas eu lieu à temps.
Une date de fin inscrite dans le certificat
Un certificat X.509 contient une période de validité, décrite par la RFC 5280, avec un instant de début et un instant de fin. Le client qui se connecte vérifie que l'heure courante tombe dans cet intervalle, que le nom demandé correspond à celui du certificat et que la chaîne remonte à une autorité de confiance. Une seule de ces vérifications qui échoue suffit à interrompre la connexion.
La date de fin n'est donc pas un ornement administratif : c'est une condition technique de la connexion. Elle ne prévient pas toute seule, ne se dégrade pas progressivement et ne laisse aucune marge. Un certificat valable la veille devient inutilisable le lendemain à la même heure, sans qu'aucun paramètre du serveur n'ait changé entre-temps.
Pourquoi les durées de validité sont courtes
Let's Encrypt explique sa position dans une note publiée en 2015 : la durée de quatre-vingt-dix jours limite les dégâts en cas de vol de clé ou d'émission erronée, et pousse à l'automatisation, présentée comme indispensable à la généralisation du HTTPS. La même note recommande un renouvellement à soixante jours, soit un tiers de la durée avant l'échéance, pour garder une marge en cas d'échec.
Le raisonnement se transpose à la plupart des autorités de certification : plus la durée est courte, plus la fenêtre d'exploitation d'un certificat compromis est étroite. La contrepartie est directe : un renouvellement manuel tous les trois mois est une tâche qui sera oubliée un jour. La durée courte transforme donc le renouvellement en processus, avec un contrôle qui doit exister même quand tout va bien.
Ce que voit le visiteur, et ce qu'il ne voit pas
Le visiteur d'un site dont le certificat a expiré reçoit un avertissement avant tout contenu, sur la plupart des navigateurs. Si le site a déployé HSTS, la RFC 6797 interdit le contournement par exception : l'utilisateur ne peut pas choisir de continuer, il doit renoncer. La sanction est immédiate et visible, ce qui en fait la partie la moins dangereuse de l'incident.
Le reste est silencieux. Un client d'API qui refuse un certificat invalide échoue sans que personne ne regarde l'écran ; une tâche de synchronisation nocturne s'arrête ; un moteur de recherche perd la page ; une messagerie qui s'appuie sur TLS peut différer ou refuser la livraison. Ces pannes ne ressemblent pas à un problème de certificat, et se diagnostiquent donc lentement.
Les causes réelles d'un renouvellement manqué
Dans la pratique, le renouvellement automatique échoue rarement par hasard. La tâche planifiée a été désactivée lors d'une migration ; le défi de validation par HTTP ne passe plus parce que le port quatre-vingt est fermé ou redirigé ; le site est passé derrière un intermédiaire qui intercepte le chemin de validation ; l'enregistrement DNS a changé de serveur et la zone ne pointe plus là où l'automate l'attend.
S'y ajoutent les causes humaines : l'alerte part vers une boîte que plus personne ne lit, le renouvellement était manuel et la personne qui le faisait a changé de poste, le quota de l'autorité a été atteint après une série d'essais. Aucune de ces causes n'est exotique ; toutes produisent le même résultat, et toutes se détectent avant l'échéance si quelqu'un regarde la date.
Détecter avant la panne, depuis l'extérieur
La seule mesure fiable est celle du certificat réellement servi, pas de celui qui est présent sur le disque. Une connexion de contrôle relève la date de fin de la chaîne envoyée par le serveur, et cette valeur est comparée à l'horloge. Un contrôle interne peut se tromper de fichier, ignorer un serveur frontal ou tester un service qui n'est pas celui que voient les visiteurs.
Les seuils utiles se placent à trente, quatorze et sept jours : le premier laisse le temps d'agir, le dernier signale une échéance imminente. Il faut aussi surveiller le journal du renouvellement automatique : une tâche qui tourne sans erreur visible et sans nouveau certificat est le cas le plus fréquent, parce qu'elle échoue à la validation tout en rendant la main proprement.
Renouveler sans interrompre le service
L'automatisation repose sur le protocole ACME, décrit par la RFC 8555 : le client prouve le contrôle du nom, l'autorité émet un nouveau certificat, le serveur le charge. Le point délicat n'est pas l'émission mais le rechargement : un rechargement de configuration remplace le certificat sans couper les connexions en cours, alors qu'un redémarrage complet les interrompt et transforme une opération de maintenance en incident.
Deux vérifications complètent le dispositif : servir la chaîne complète, y compris les certificats intermédiaires, et conserver l'ancien certificat jusqu'à ce que le nouveau soit vérifié depuis l'extérieur. Un renouvellement réussi côté outil mais incomplet côté chaîne produit exactement le même symptôme qu'une expiration, avec une cause différente et un diagnostic plus long.
La panne la plus évitable d'un parc
Un certificat expiré n'a rien d'un accident technique imprévisible : la date est connue à l'avance, dès l'émission. La seule inconnue est la présence de quelqu'un ou de quelque chose qui la regarde. C'est pourquoi la vérification compte davantage que l'outil : un inventaire des certificats du parc, y compris ceux des services de messagerie et des interfaces d'administration, vaut mieux qu'un renouvellement automatisé dont personne ne contrôle le résultat.
Trois pratiques suffisent à faire disparaître cette cause de panne : automatiser l'émission, vérifier depuis l'extérieur la date réellement servie, et alerter assez tôt pour agir un jour ouvré. Aucune ne demande d'outil propriétaire, et chacune se teste en provoquant volontairement une échéance courte sur un site de test, plutôt qu'en découvrant le mécanisme le jour où le site principal tombe.