Résumé

  • Le 21 avril 2026, Geoff Huston a révoqué un certificat de test Let’s Encrypt puis retrouvé son numéro de série sur la liste de révocation. Quarante-huit heures plus tard, les trois versions de navigateur testées acceptaient encore sa connexion.
  • Dans sa présentation ultérieure à l’APNIC 62, Firefox finissait par refuser ce même certificat après quelques semaines; Chrome et Safari l’acceptaient toujours dans son essai. Entre la publication d’un statut et son application, le temps compte.

On peut publier un avis de décès et voir le défunt entrer par la grande porte. Huston a créé un certificat Let’s Encrypt pour un site de test, l’a révoqué quatre heures plus tard, le 21 avril 2026, puis a vérifié sa présence sur la liste de l’émetteur. Cette partie de l’opération avait fonctionné. La surprise est arrivée dans la fenêtre du navigateur.

Son récit publié par l’APNIC nomme les versions : Firefox 148.0.2, Chrome 147.0.7727.117 et Safari 25.4 acceptaient encore la connexion après 48 heures. Il s’agit d’un essai daté sur un seul certificat. Cela suffit à poser une question précise. Quand l’autorité change un statut, qui transporte cette information jusqu’au logiciel qui décide d’ouvrir la session TLS ? La liste n’a pas de main pour fermer la porte.

Quelques semaines plus tard, le tableau n’était plus identique. Dans ses diapositives de l’APNIC 62, Firefox rejetait enfin le certificat; Chrome et Safari l’acceptaient encore lors du test. Lire l’article d’avril et l’exposé de septembre comme deux photographies prises à des instants différents évite une fausse contradiction. La durée de ce décalage est le véritable résultat éditorial : « révoqué » sur le serveur de l’émetteur peut coexister avec « accepté » chez l’utilisateur.

Huston déroule ensuite les modes de transmission de la mauvaise nouvelle. Télécharger les listes coûte du volume. Interroger un service de statut ajoute un délai, une dépendance de disponibilité et une trace des connexions de l’utilisateur. Joindre une réponse au dialogue TLS épargne une requête, mais le serveur qui présente sciemment un certificat révoqué n’a guère intérêt à fournir lui-même la pièce à conviction. Les flux de révocation intégrés aux navigateurs donnent encore une autre réponse à la question de la fraîcheur.

Raccourcir la vie des certificats n’efface pas la révocation anticipée. Passer de 90 à 45 jours, puis à six, réduit le temps d’exposition; l’incident peut toujours survenir au début de la période. Une validité de quelques heures changerait brutalement la charge de renouvellement. Huston termine par une proposition plus radicale : publier la clé du service dans le DNS, la protéger avec DNSSEC, utiliser le TTL pour borner l’âge d’une réponse et éventuellement joindre la chaîne de validation à la connexion. C’est son projet présenté à l’APNIC 62, pas une migration déjà accomplie du Web. Il remet au centre la question utile : combien de temps une affirmation d’authenticité peut-elle vieillir avant d’être vérifiée à nouveau ?