En tant qu’entreprise de surveillance et d’observabilité, nous avons également beaucoup de surveillance intégrée à nos systèmes. Nous avons la surveillance standard pour nous assurer que les systèmes fonctionnent correctement, que les données circulent dans notre infrastructure, etc. En même temps, nous surveillons tout changement soudain des tests que nos clients exécutent.
Le 29 septembre 2021, à 19:21:40 UTC, nous avons commencé à voir un tsunami d’alertes à Catchpoint. Ils proviennent de certains de nos tests Web à partir de nos nœuds synthétiques, se produisant lorsque notre certificat Let’s Encrypt « R3 » a expiré. Ces types d’incidents sont assez rares.
Un autre exemple s’est produit en 2020 lorsque le certificat racine Sectigo AddTrust a expiré. La différence avec cet événement était que beaucoup plus de serveurs s’appuient sur des certificats Let’s Encrypt.
La cause première de la crise n’était pas Catchpoint, notre produit ou un quelconque employé, mais un problème lié aux modifications apportées au chemin du certificat par un émetteur de certificat. De plus, comme nous travaillons avec de nombreux fournisseurs, nous avons reçu des mises à jour de certains qui indiquent que la résolution de ce problème est aussi simple que de télécharger les dernières mises à jour du système d’exploitation. Bien que cela soit vrai pour certains, ça ne résout pas le problème en général !
Ci-dessous, nous expliquons pourquoi et comment le résoudre côté serveur afin que tous vos clients puissent accéder à votre service Web sans problème. Nous partageons également notre examen de l’incident de l’événement, afin que les apprentissages puissent aider les autres.
Faites-vous confiance à Let’s Encrypt ?
Avant d’entrer dans le vif du sujet, je veux juste dire que, personnellement, je fais confiance à Let’s Encrypt. C’est une excellente entreprise qui a rendu la gestion des certificats extrêmement accessible à tous et extrêmement conviviale pour les développeurs.
En partie à cause d’eux, le nombre de sites Web utilisant le cryptage a explosé ces dernières années. Le cryptage est extrêmement important sur Internet. C’est la base des communications sécurisées. Que vous vérifiiez votre solde bancaire, que vous achetiez une nouvelle paire de chaussettes chez un e-commerçant ou que vous parliez à vos amis, vous le faites en partant du principe que cette transaction est sécurisée.
Au cours des 8 dernières années (2013-2020), le pourcentage de pages Web utilisant HTTPS est passé de 25 % à plus de 84 % ! Il y a plusieurs raisons à cette croissance incroyable. L’un d’eux est que Google a progressivement forcé les sites à utiliser HTTPS en rendant les sites basés sur HTTP « non sécurisés ». Pourtant, quelle qu’en soit la cause, en ce laps de temps, Let’s Encrypt est passé de l’émission de certificats pour environ 50 millions de sites Web à plus de 230 millions !
En même temps, peu importe que je fasse confiance à Let’s Encrypt si les ordinateurs ne le font pas. C’est exactement ce qui s’est passé le soir du 29 septembre et à nouveau le matin du 30 septembre 2021.
Comment fonctionne la confiance des certificats numériques
Voici un bref résumé de la façon dont certificat de confiance fonctionne sur Internet :
Certificats racine
Il existe une poignée de certificats racine. Ceux-ci sont émis par de grandes entreprises sous beaucoup d’examen minutieux et sont installés dans le Magasins de certificats d’ordinateurs dans le monde par la société qui a développé et maintient le système d’exploitation. Si vous disposez d’un ordinateur pouvant se connecter à un site Web HTTPS, vous disposez d’un tel magasin de certificats. En ce moment, l’ordinateur portable MacOS sur lequel j’écris ceci a 161 « certificats racine système » installés.
Chaîne de confiance
Lorsque quelqu’un lance un site Web de nos jours, il doit prendre en charge HTTPS. Par conséquent, ils achètent un certificat auprès d’un fournisseur. Il existe de nombreux fournisseurs parmi lesquels choisir. Certains ont leur propre certificat racine et d’autres ont un Autorité de certification certificat, qui a été signé par l’un des certificats racine ou par un autre Autorité de certification. De cette façon, il existe un chaîne de confiance du certificat du site Web jusqu’au certificat racine.
Certificats intermédiaires
Lorsque vous vous rendez sur le site Web HTTPS, le serveur hébergeant le site Web envoie le certificat lors de la prise de contact SSL avec le client (navigateur/client HTTP). Il peut également vous envoyer un ou plusieurs certificats intermédiaires. Ces certificats intermédiaires sont ce dont vous pensez avoir besoin pour connecter la chaîne de confiance du certificat de serveur à l’un des certificats racine que vous avez installés sur votre ordinateur.
Processus de validation
Votre navigateur « parcourt » la chaîne de confiance, du certificat du serveur jusqu’à la racine. S’il parvient jusqu’à la racine et le trouve dans son « magasin », la chaîne est validée et la connexion est autorisée à se poursuivre. Sinon, vous obtenez un avertissement de sécurité comme celui ci-dessous.
L’expiration du certificat R3 et la chaîne de confiance…
Passons en revue les détails de ce qui s’est passé :
Comme mentionné, les premiers problèmes que nous avons rencontrés avec les tests Web de nos nœuds synthétiques ont commencé à 19:21:40 UTC le 29 septembre lorsque le certificat Let’s Encrypt « R3 » a expiré. Voici les informations de certificat pour ce certificat intermédiaire :
https://crt.sh/?id=3479778542
L’information la plus importante ici est la date d’expiration. Puisqu’il s’agit d’un certificat intermédiaire, cela signifie que Let’s Encrypt a utilisé ce certificat pour signe d’autres certificats pour leurs clients. Par exemple:
La capture d’écran montre un site Web dont le certificat a été signé avec ce certificat R3. Dès que le certificat a expiré, ce site n’était plus accessible ! Un navigateur qui tenterait de valider le certificat du site Web parcourrait la chaîne de confiance et découvrirait que le certificat intermédiaire a expiré. C’est alors que vous obtenez des erreurs effrayantes comme celle-ci dans votre navigateur :
Let’s Encrypt a publié un nouveau certificat R3 ! La nouvelle date d’expiration est en 2025 – bien loin. Tout va bien, non ? Eh bien, pas tout à fait.
Il s’avère que le certificat doit être mis à jour sur votre ordinateur – généralement via une mise à jour Windows ou MacOS – avant de fonctionner. Cependant, beaucoup de gens ne mettent pas à jour leurs ordinateurs aussi souvent qu’ils le devraient. Pire encore, de nombreux appareils embarqués mettent rarement, voire jamais, leurs certificats à jour ! Quelqu’un ici à Catchpoint a mentionné que ses enfants ne pouvaient pas regarder leur émission en streaming préférée depuis sa SmartTV à cause de ce problème !
Alors, d’accord – disons que vous avez le dernier certificat intermédiaire R3 installé dans l’ensemble de votre flotte d’appareils. Vous pouvez désormais accéder à l’un de ces millions de sites avec les certificats Let’s Encrypt, n’est-ce pas ? Eh bien, en quelque sorte… jusqu’à 10 h 00 heure de l’Est le lendemain matin.
30 septembre, 10 h HNE : expiration du certificat DST Root CA X3 et conséquences
À 10 heures du matin le 30 septembre, le certificat DST Root CA X3 a expiré. Les détails sont un peu déroutants mais supportez-moi.
A l’origine, le DST Root CA X3 était utilisé pour signer tous les certificats Let’s Encrypt (y compris le certificat intermédiaire R3 ci-dessus). Let’s Encrypt a également signé les certificats en utilisant leur propre certificat ISRG Root X1. Cela a été fait parce que le certificat DST était déjà présent dans la plupart des navigateurs et des appareils. Cependant, le certificat ISRG ne l’était pas.
Au fur et à mesure que Let’s Encrypt est devenu plus connu et que le certificat ISRG était disponible sur tous les principaux appareils, ils ont cessé de se fier au certificat DST.
Voici le diagramme de Let’s Encrypt de leur hiérarchie de certificats :
Notez que tous les certificats de serveur (« certificats d’abonné ») qui ont été signés par R3 ont été signés par la racine DST ou la racine ISRG, ou, très probablement, signés par les deux.
Voici les informations du certificat racine DST : https://crt.sh/?id=8395
Ce que vous verrez, c’est qu’il existe en fait deux versions du certificat ISRT Root X1 : https://crt.sh/?id=3958242236 et https://crt.sh/?id=9314791. Le second est auto-signé. C’est bien pour un certificat Root CA qui est présent dans la plupart des appareils à travers le monde. Le premier, cependant, est signé par DST Root CA X3 !
Lorsque le certificat racine DST a expiré, cela a causé des problèmes pour deux classes de systèmes :
- Les systèmes qui ne disposaient pas d’une copie mise à jour du certificat ISRT Root X1 ont commencé à ne pas se connecter aux sites à l’aide de Let’s Encrypt car leur certificat de site était signé par R3, qui a été signé par ISRG, qui a été signé par DST – qui était expiré !
- Systèmes qui disposaient de la copie correctement mise à jour du certificat racine ISRT X1 mais souhaitaient valider le certificat racine DST De toute façon, car il a signé le certificat R3 !
Correctifs, correctifs
La première catégorie était relativement facile à corriger : mettre à jour le système d’exploitation ou télécharger le nouveau certificat et l’installer, en supposant qu’il ne s’agisse pas d’un périphérique intégré qui n’a pas publié de mise à jour.
Le second est plus dur. Par exemple, tout logiciel qui repose sur OpenSSL 1.0.2 ou une version antérieure aura ce problème – et il n’y a aucun moyen pour le client de le réparer.
Pensez-y de cette façon : généralement, votre site Web envoie le certificat du serveur et tous les certificats intermédiaires dont le client pourrait avoir besoin. Lorsque le client parcourt la chaîne de certificats, il voit le certificat de site signé par R3. Ensuite, il voit que R3 est signé par ISRG, mais aussi par DST – certains navigateurs ou autres clients HTTP n’en valident qu’un. Ils constatent alors que le certificat ISRG est valide et ils sont satisfaits. D’autres ont besoin des deux pour être valides, mais ils ne le sont pas, car le certificat DST a expiré !
Si vous exécutez un site Web et que vous souhaitez que les clients puissent se connecter à partir d’appareils tels que ceux-ci, il n’y a qu’une seule solution : régénérez le certificat que votre site utilise afin qu’il ne soit plus signé par le certificat DST. Ensuite, votre serveur arrêtera de l’envoyer au client pour validation, et le client ne manquera pas de le valider.
Ceci est particulièrement important si vous disposez de services basés sur HTTPS auxquels les navigateurs d’un ordinateur portable n’accèdent pas directement. Peut-être que vous servez des flux RSS ou avez une API accessible par des appareils intégrés. Peut-être que vos clients accèdent réellement au site via un proxy (il est plus probable que certains des utilisateurs essayant d’accéder à votre serveur ne puissent pas en raison de ce problème).
![]()
Résoudre ce problème sur votre serveur
Voici comment j’ai résolu le problème sur un serveur de test. Veuillez noter que certains clients peuvent toujours ignorer la chaîne de certificats envoyée par le serveur, donc aucune garantie que cela résoudra le problème pour tous, mais cela devrait le résoudre pour les clients modernes/conformes. Ceci n’est qu’un exemple : veuillez suivre les procédures appropriées pour demander et mettre à jour les certificats de votre environnement !
La première chose que j’ai faite a été de renouveler mon certificat. Beaucoup de gens pensaient que c’était suffisant, mais il s’avère que la chaîne de certificats configurée par l’outil Let’s Encrypt incluait toujours le certificat ISRG signé par DST !
Vous pouvez vérifier cela en utilisant openssl s_client (openssl s_client-connect www.site.com:443 –showcerts)
Cela signifie que lorsqu’un client se connecte à ce serveur, il enverra cette chaîne et certains clients tenteront de valider ISRG en utilisant DST. Après tout, il est émis par DST !
Sur mon système (Ubuntu 18.04 LTS avec Apache 2 et le certbot de Let’s Encrypt installé), les certificats se trouvent dans /etc/letsencrypt/live/www.mysite.com/fullchain.pem. Les chaînes de certificats sont répertoriées dans l’ordre, la dernière de ce fichier est donc le certificat ISRG incorrect. J’ai obtenu la dernière version à partir d’ici : https://crt.sh/?id=9314791 (il y a un lien de téléchargement sur le côté gauche), et j’ai remplacé celui de fullchain.pem. Après avoir redémarré le serveur Web, j’ai maintenant la bonne chaîne proposée.
Maintenant, le serveur envoie le certificat racine ISRG auto-signé, qu’un client mis à jour pourra valider sans avoir besoin du certificat racine DST expiré.
En conclusion…
Chez Catchpoint, nous avons une énorme empreinte d’agents de test dans tous les coins du monde. Ces agents ont différentes configurations matérielles, logicielles, micrologicielles, etc. En raison de cette grande flotte, nous avons vu et résolu presque…