Let's Encrypt arrête tout : trois heures sans certificats

Ce qui s'est passé

Vendredi 8 mai 2026, à 18h37 UTC, les ingénieurs de Let's Encrypt ont déclenché un arrêt d'urgence de toute leur infrastructure d'émission de certificats. Pendant deux heures et demie, aucun nouveau certificat TLS n'a pu être délivré, ni aucun renouvellement automatique n'a pu aboutir. Pour une autorité de certification qui sert plus de 600 millions de domaines à travers le monde, l'incident sort largement du cadre d'une simple maintenance.

L'origine du problème se situe dans la chaîne de confiance elle-même. Let's Encrypt est en train de déployer une nouvelle racine baptisée Generation Y, destinée à remplacer à terme la racine Generation X qui sert l'écosystème depuis plusieurs années. Pour assurer la continuité, la nouvelle racine est cross-signée par l'ancienne, ce qui permet aux clients qui ne connaissent pas encore Generation Y de continuer à valider les certificats grâce au lien cryptographique avec Generation X. C'est ce certificat cross-signé qui a posé problème : un défaut a été détecté dans son contenu, suffisamment grave pour que les équipes décident de couper le robinet plutôt que de continuer à signer des certificats potentiellement défectueux.

Les composants impactés couvrent l'ensemble des points d'entrée publics du service. Les API ACME de production (acme-v02.api.letsencrypt.org) et de staging (acme-staging-v02.api.letsencrypt.org) ont été stoppées simultanément, ainsi que les portails de production et de staging hébergés sur deux datacenters de haute disponibilité. Concrètement, tout client utilisant Certbot, acme.sh, lego, ou n'importe quel client ACME tiers a vu ses requêtes échouer pendant la fenêtre de panne. Les profils de certificat les plus exposés étaient tlsserver, le profil par défaut pour les certificats web, et shortlived, le profil expérimental destiné aux certificats à durée de vie réduite.

À 21h03 UTC, soit deux heures et demie après le début de l'incident, Let's Encrypt a confirmé la reprise de l'émission. La solution retenue dans l'urgence a été de repasser intégralement sur la racine Generation X et de mettre en pause le déploiement progressif de Generation Y. Cette bascule a permis de contourner le certificat cross-signé défectueux sans avoir à le révoquer immédiatement, mais elle reporte de fait le calendrier de transition vers la nouvelle racine.

Selon Let's Encrypt, aucune fuite de clé privée ni aucun certificat malveillant n'a été émis pendant l'incident. Il s'agissait bien d'un défaut de configuration de la chaîne de confiance, identifié de façon proactive par les équipes internes, et non d'une compromission. La transparence dont fait preuve l'autorité, avec une page de statut détaillée et un post-mortem prévu, est cohérente avec les pratiques imposées par les forums CA/Browser et les exigences de transparence des certificats (Certificate Transparency).

L'impact opérationnel sur les administrateurs systèmes a été réel mais maîtrisé. Les certificats déjà émis et déployés ont continué à fonctionner normalement, puisque le problème ne concernait que l'émission de nouveaux certificats. En revanche, tous les jobs cron de renouvellement automatique qui tournaient pendant la fenêtre de 150 minutes ont échoué et devaient retenter leur opération. Pour les certificats arrivant à expiration dans la nuit du 8 au 9 mai, certains administrateurs ont dû relancer manuellement leurs renouvellements après le rétablissement.

Cet incident s'inscrit dans une période de transformation profonde pour Let's Encrypt. L'autorité a annoncé en 2026 son passage à des certificats de 45 jours, contre 90 jours historiquement, un changement qui multiplie par deux le volume de renouvellements quotidiens. La nouvelle racine Generation Y était conçue pour accompagner ce passage à un cycle plus court et offrir des garanties cryptographiques modernisées. La pause forcée du 8 mai oblige à revoir le calendrier sans pour autant remettre en cause la stratégie générale.

Selon les premières analyses publiées par la communauté, l'incident souligne la fragilité inhérente aux opérations de cross-signing. Lorsqu'une racine est utilisée pour signer une autre racine, la moindre erreur dans les extensions, les contraintes de noms ou les politiques d'usage se propage à tous les certificats émis sous la nouvelle hiérarchie. Le post-mortem complet de Let's Encrypt, attendu dans les jours qui viennent, devrait préciser quelle composante exacte du certificat cross-signé était en cause.

Pourquoi c'est important

Let's Encrypt n'est plus une initiative de niche : l'autorité émet aujourd'hui environ la moitié des certificats TLS publiquement valides à l'échelle mondiale. Une coupure de deux heures et demie sur son infrastructure d'émission n'a probablement pas eu d'effet immédiatement visible sur la majorité des sites web déjà servis, mais elle illustre une dépendance critique de l'écosystème internet à un acteur unique. Si la coupure avait duré 24 heures au lieu de 150 minutes, des dizaines de millions de certificats arrivés à expiration n'auraient pas pu être renouvelés à temps, déclenchant des erreurs TLS en cascade sur des sites de e-commerce, des API publiques et des services critiques.

Le contexte plus large est celui de la modernisation des chaînes de confiance. Plusieurs autorités de certification, dont Let's Encrypt, sont engagées dans des transitions de racine pour passer à des courbes elliptiques modernes, à des durées de validité plus courtes et à des politiques d'usage plus strictes imposées par les navigateurs. Apple, Google et Mozilla ont tous publié ces dernières années des feuilles de route exigeant un raccourcissement progressif de la durée de vie maximale des certificats serveurs, jusqu'à 47 jours à l'horizon 2027 selon le calendrier voté par le forum CA/Browser. Cette pression réglementaire impose aux autorités de cycler leurs racines plus souvent, ce qui multiplie les opérations à risque comme le cross-signing.

Pour les entreprises, l'incident remet sur la table une question rarement posée : quelle est la stratégie de continuité en cas d'indisponibilité prolongée d'une autorité de certification ? Les bonnes pratiques recommandent de configurer plusieurs comptes ACME, voire d'utiliser plusieurs autorités en parallèle (Let's Encrypt, ZeroSSL, Buypass, Google Trust Services) avec des mécanismes de failover automatiques au niveau des clients ACME. Très peu d'organisations le font en production, par habitude ou par méconnaissance des risques, et l'épisode du 8 mai pourrait inciter certaines DSI à revoir leur architecture de gestion des certificats.

Sur le plan réglementaire, l'incident sera observé avec attention par les autorités européennes qui finalisent l'application du règlement eIDAS 2 et l'arrivée des navigateurs qualifiés (QWAC). Les opérateurs de certificats qualifiés et les autorités de certification soumises à eIDAS doivent fournir des garanties de continuité d'émission et notifier les incidents dans des délais courts. Bien que Let's Encrypt ne soit pas une autorité qualifiée eIDAS, son comportement transparent et sa réactivité serviront de référence implicite pour les attentes du marché en matière de gestion d'incidents PKI.

Ce qu'il faut retenir

• L'incident a duré deux heures et demie, du 8 mai 18h37 UTC au 8 mai 21h03 UTC, et n'a généré aucune fuite ni aucun certificat malveillant.
• Le déploiement de la racine Generation Y est mis en pause ; toutes les nouvelles émissions repassent sur Generation X jusqu'à correction du certificat cross-signé.
• Vérifiez vos logs ACME pour la fenêtre concernée et relancez manuellement les renouvellements qui auraient échoué silencieusement, en particulier sur les certificats à expiration courte (profils shortlived, certificats de 45 jours).