Abonnez-vous pour recevoir des notifications sur les nouveaux articles :

Comment nous nous assurons que les clients de Cloudflare ne sont pas affectés par le changement de chaîne de certificats de Let's Encrypt

2024-04-12

Lecture: 10 min.
Cet article est également disponible en English, en 繁體中文, en Deutsch, en 日本語, en 한국어, en Español et en 简体中文.

Let's Encrypt, une autorité de certification (CA) publiquement reconnue, utilisée par Cloudflare pour émettre des certificats TLS, s'appuie sur deux chaînes de certificats distinctes. La première chaîne à signature croisée utilise avec IdenTrust, une autorité de certification mondialement reconnue créée en 2000, tandis que la seconde utilise l'autorité de certification racine de Let's Encrypt, ISRG Root X1. Depuis le lancement de Let's Encrypt, ISRG Root X1 améliore régulièrement sa compatibilité avec les appareils.

How we ensure Cloudflare customers aren't affected by Let's Encrypt's certificate chain change

Le 30 septembre 2024, la chaîne de certificats à signature croisée de Let's Encrypt utilisant IdenTrust expirera. Après l'expiration de la signature croisée, les serveurs ne seront plus en mesure de servir les certificats signés par la chaîne à signature croisée. Au lieu de cela, tous les certificats de Let's Encrypt utiliseront l'autorité de certification ISRG Root X1.

La plupart des versions d'appareils et de navigateurs publiées après 2016 ne rencontreront aucun problème suite au changement, puisque ISRG Root X1 sera déjà installé dans les Trust Stores de ces clients. En effet, ces navigateurs et systèmes d'exploitation modernes ont été conçus pour allier agilité et flexibilité, avec des Trust Stores évolutifs, pouvant être mis à jour afin d'inclure de nouvelles autorités de certification.

Le changement de chaîne de certificats aura une incidence sur les anciens appareils et systèmes, tels que les appareils exécutant Android version 7.1.1 (publié en 2016) ou des versions antérieures, car celles-ci reposent exclusivement sur la chaîne à signature croisée et ne disposent pas du certificat racine ISRG Root X1 dans leur Trust Store. Ces clients rencontreront des erreurs ou des avertissements TLS lorsqu'ils accéderont à des domaines sécurisés avec un certificat Let's Encrypt. Nous avons nous-mêmes examiné les données et avons constaté que, sur l'ensemble des requêtes adressées à Android, 2,96 % provenaient d'appareils qui seront affectés par le changement. Cela représente une partie considérable de trafic qui n'aura plus accès à Internet. Nous nous engageons à préserver la présence en ligne de ces utilisateurs, et nous modifierons notre pipeline de certificats afin de pouvoir continuer à servir des utilisateurs sur des appareils plus anciens, sans exiger de modifications manuelles de la part de nos clients.

Un Internet meilleur pour tous

Par le passé, nous avons investi dans des initiatives telles que « No Browsers Left Behind » afin de nous assurer de pouvoir continuer à prendre en charge des clients tandis que les algorithmes basés sur SHA-1 devenaient obsolètes. Nous appliquons désormais la même approche pour le futur changement affectant Let's Encrypt.

Nous avons pris la décision de supprimer Let's Encrypt en tant qu'autorité de certification de tous les flux pour lesquels l'autorité de certification est dictée par Cloudflare, ce qui affecte les clients utilisateurs de Universal SSL et les clients utilisant SSL for SaaS avec le choix « Default CA » (autorité de certification par défaut).

À partir de juin 2024, soit un cycle de vie de certificat (90 jours) avant l'expiration de la chaîne à signature croisée, nous commencerons la migration des certificats Let's Encrypt devant être renouvelés vers une autre autorité de certification permettant de garantir la compatibilité avec les appareils plus anciens concernés par le changement. Cela signifie qu'à l'avenir, les clients ne recevront des certificats Let's Encrypt que s'ils demandent explicitement à utiliser Let's Encrypt en tant qu'autorité de certification.

Le changement qu'effectue Let's Encrypt est nécessaire. Pour nous permettre d'évoluer vers la prise en charge de normes et de protocoles nouveaux, nous devons rendre l'écosystème de l'infrastructure à clé publique (PKI, Public Key Infrastructure) plus agile. En supprimant la chaîne à signature croisée, Let's Encrypt incite les appareils, les navigateurs et le client à prendre en charge des Trust Stores adaptables.

Cependant, nous avons observé des changements similaires dans le passé et, bien qu'ils promeuvent l'adoption de nouvelles normes, ils affectent de manière disproportionnée les utilisateurs situés dans des régions économiquement désavantagées, où l'accès aux nouvelles technologies est limité.

Notre mission consiste à développer un Internet meilleur, et cela implique de soutenir les utilisateurs du monde entier. Nous avons précédemment publié un article de blog consacré au changement affectant Let's Encrypt, dans lequel nous invitions les clients à changer d'autorité de certification s'ils s'attendent à être affectés par ce changement. Cependant, il est difficile d'en déterminer l'impact. La journalisation des erreurs liées à l'incompatibilité des Trust Stores se déroule principalement au niveau des clients, ce qui réduit la visibilité dont disposent les propriétaires de domaines. En outre, bien qu'aucune requête ne provienne d'appareils incompatibles aujourd'hui, cela ne garantit pas qu'un utilisateur bénéficiera d'un accès ininterrompu demain.

Le pipeline de certificats de Cloudflare a évolué au fil des ans, devenant résilient et flexible, ce qui nous permet de nous adapter avec fluidité à des changements tels que celui-ci sans incidence préjudiciable pour nos clients.

Comment Cloudflare a bâti un pipeline de certificats TLS solide

Aujourd'hui, Cloudflare gère des dizaines de millions de certificats pour le compte de ses clients. Pour nous, un pipeline performant offre les avantages suivants :Les clients peuvent toujours obtenir un certificat TLS pour leur domaine

  1. Les clients peuvent toujours obtenir un certificat TLS pour leur domaine

  2. Les problèmes liés aux autorités de certification n'ont aucun impact sur la capacité de nos clients à obtenir un certificat

  3. La mise en œuvre de bonnes pratiques de sécurité et de normes modernes

  4. L'optimisation de l'infrastructure pour les évolutions futures

  5. Une vaste sélection de clients et d'appareils sont pris en charge

Chaque année, nous inaugurons de nouvelles optimisations dans notre pipeline de certificats, afin de maintenir un niveau de service inégalé. Voici les dispositions que nous prenons pour y parvenir.

Veiller à ce que les clients puissent toujours obtenir un certificat TLS pour leur domaine

Depuis le lancement de Universal SSL en 2014, Cloudflare est responsable de l'émission et de la diffusion d'un certificat TLS pour chaque domaine protégé par notre réseau. Cela peut sembler trivial, mais quelques étapes doivent être mises en œuvre avec succès pour qu'un domaine reçoive un certificat :L'autorité de certification doit vérifier le jeton de validation de contrôle de domaine pour émettre le certificat.

  1. Les propriétaires de domaines doivent effectuer une validation de contrôle de domaine (Domain Control Validation, DCV) pour chaque émission et renouvellement d'un certificat.

  2. L'autorité de certification doit vérifier le jeton de validation de contrôle de domaine pour émettre le certificat.

  3. Les enregistrements CAA (Certification Authority Authorization, autorisation d'autorité de certification), qui dictent les autorités de certification pouvant être utilisées pour un domaine, doivent être vérifiés pour garantir que seules les parties autorisées puissent délivrer le certificat.

  4. L'autorité de certification doit être disponible pour émettre le certificat.

Chacune de ces étapes nécessite une coordination entre un certain nombre de parties : propriétaires de domaines, réseaux de diffusion de contenu (CDN) et autorités de certification. Chez Cloudflare, nous aspirons à maîtriser les conditions qui déterminent le succès de notre plateforme. C'est pourquoi nous nous efforçons de veiller à ce que chacune de ces étapes puisse être mise en œuvre avec succès.

Nous veillons à ce que chaque émission et chaque renouvellement de certificat exige des efforts minimaux de la part de nos clients. Pour obtenir un certificat, un propriétaire de domaine doit effectuer la validation de contrôle de domaine (Domain Control Validation, DCV) afin de prouver qu'il est bien propriétaire du domaine. Une fois la requête de certificat lancée, l'autorité de certification renvoie des jetons DCV, que le propriétaire du domaine devra placer dans un enregistrement DNS ou un jeton HTTP. Si vous utilisez Cloudflare comme fournisseur DNS, Cloudflare complète la procédure DCV en votre nom en plaçant automatiquement le jeton TXT renvoyé par l'autorité de certification dans vos enregistrements DNS. Par ailleurs, si vous utilisez un fournisseur DNS externe, nous vous offrons la possibilité de déléguer la procédure DCV à Cloudflare, afin de bénéficier de renouvellements automatiques, sans intervention du client.

Une fois placés, les jetons DCV sont vérifiés par les autorités de certification (CA, Certificate Authorities). Les autorités de certification effectuent cette vérification depuis plusieurs points de vue, afin d'empêcher les tentatives d'usurpation. Cependant, puisque ces vérifications sont effectuées depuis plusieurs pays et ASN (Autonomous System, système autonome), elles peuvent déclencher une règle du pare-feu WAF de Cloudflare, qui peut entraîner le blocage de la vérification de la procédure DCV. Nous avons veillé à mettre à jour notre pare-feu WAF et notre moteur de sécurité, afin qu'ils reconnaissent que ces requêtes proviennent d'une autorité de certification ; nous pouvons ainsi nous assurer qu'elles ne seront jamais bloquées et que la procédure DCV pourra être finalisée.

Certains clients ont des préférences concernant les autorités de certification, en raison d'exigences internes ou de réglementations en matière de conformité. Pour empêcher une autorité de certification non autorisée d'émettre un certificat pour un domaine, le propriétaire du domaine peut créer un enregistrement DNS CAA (Certification Authority Authorization, autorisation d'autorité de certification), en précisant quelles autorités de certification sont autorisées à émettre un certificat pour ce domaine. Pour garantir que les clients puissent toujours obtenir un certificat, nous vérifions les enregistrements CAA avant de demander un certificat, afin de savoir quelles autorités de certification nous devons utiliser. Si les enregistrements CAA bloquent toutes les autorités de certification disponibles dans le pipeline de Cloudflare et le client n'a pas transféré de certificat depuis l'autorité de certification de son choix, nous ajoutons alors les enregistrements CAA pour le compte de nos clients, afin de nous assurer qu'ils puissent obtenir l'émission d'un certificat. Lorsque nous le pouvons, nous optimisons en fonction des préférences. Dans le cas contraire, notre rôle est de prévenir les pannes en nous assurant qu'un certificat TLS soit toujours disponible pour le domaine, même s'il ne provient pas d'une autorité de certification préférée.

Aujourd'hui, Cloudflare n'est pas une autorité de certification publiquement reconnue ; nous comptons donc sur les autorités de certification que nous utilisons pour garantir une disponibilité élevée. Toutefois, exiger une disponibilité de 100 % constitue une attente irréaliste. Au lieu de cela, notre pipeline doit être préparé pour l'éventualité où nos autorités de certification seraient indisponibles.

Veiller à ce que les problèmes liés aux autorités de certification n'aient aucun impact sur la capacité de nos clients à obtenir un certificat

Chez Cloudflare, nous aimons anticiper les événements, ce qui signifie prévenir les incidents avant qu'ils ne se produisent. Il n'est pas rare que des autorités de certification soient indisponibles ; parfois, cela se produit en raison d'une panne, mais plus fréquemment, les autorités de certification imposent des périodes de maintenance pendant lesquelles elles sont temporairement indisponibles.

Notre rôle est d'assurer la redondance des autorités de certification ; c'est pourquoi nous disposons toujours de plusieurs autorités de certification prêtes à émettre un certificat, afin d'assurer une disponibilité élevée à tout moment. Si vous avez remarqué que vos certificats Universal SSL sont émis par différentes autorités de certification, c'est intentionnel. Nous répartissons uniformément la charge sur nos autorités de certification, afin d'éviter tout point de défaillance unique. En outre, nous surveillons de près la latence et les taux d'erreur, afin de détecter d'éventuels problèmes et de basculer automatiquement vers une autre autorité de certification disponible et performante. Vous ne le savez peut-être pas, mais l'une de nos autorités de certification impose chaque mois environ quatre périodes de maintenance programmées. Lorsque cela se produit, nos systèmes automatisés se déclenchent de manière fluide, afin d'assurer que tout fonctionne bien. Cela se déroule tellement bien que nos équipes internes ne sont même plus alertées, car tout fonctionne, tout simplement.

Adopter des bonnes pratiques de sécurité et des normes modernes

La sécurité a toujours été, et continuera d'être, la priorité absolue de Cloudflare ; il est donc essentiel de maintenir les normes de sécurité les plus strictes pour protéger les données et les clés privées de nos clients.

Au cours de la dernière décennie, le consortium CA/Browser Forum a plaidé en faveur de la réduction de la durée de vie des certificats de 5 ans à 90 jours, qui constitue la norme dans le secteur. Cette évolution contribue à minimiser le risque de compromission de clés. Lorsque les certificats sont renouvelés tous les 90 jours, leurs clés privées ne restent valables que pendant cette période, réduisant la fenêtre pendant laquelle un acteur malveillant peut utiliser les informations compromises.

Nous soutenons pleinement ce changement, et nous avons défini à 90 jours la durée de validité par défaut des certificats. Ceci permet d'améliorer notre stratégie de sécurité, en garantissant des renouvellements réguliers des clés, et nous a incités à développer des outils tels que DCV Delegation, qui encouragent l'automatisation autour des renouvellements de certificats fréquents, sans entraîner de frais supplémentaires. C'est ce qui nous permet de proposer des certificats avec des périodes de validité pouvant atteindre deux semaines seulement aux clients qui désirent renouveler fréquemment leurs clés privées, sans se préoccuper des échecs de renouvellement de certificat.

Cloudflare a toujours évolué à l'avant-garde des nouveaux protocoles et normes. Ce n'est un secret pour personne : lorsque nous prenons en support un nouveau protocole, son adoption explose. Ce mois-ci, nous ajouterons la prise en charge de l'algorithme ECDSA pour les certificats émis par Google Trust Services. Avec ECDSA, vous bénéficiez du même niveau de sécurité qu'avec RSA, toutefois, avec des clés plus petites. Des clés plus petites signifient des certificats plus petits et permettent de réduire la quantité de données transmises pour établir une connexion TLS, ce qui se traduit par des connexions et des temps de chargement plus rapides.

L'optimisation de l'infrastructure pour les évolutions futures

Aujourd'hui, Cloudflare émet près d'un million de certificats par jour. Avec la récente transition vers des durées de vie de certificats plus courtes, nous continuons d'améliorer notre pipeline afin de le rendre plus robuste. Toutefois, même si notre pipeline est en mesure de gérer cette charge importante, nous devons encore avoir l'assurance que nos autorités de certification sont capables d'évoluer avec nous. Chaque fois que nous intégrons une autorité de certification, nous devenons instantanément l'un de ses plus grands consommateurs. Nous exigeons de nos autorités de certification des normes strictes, et nous les incitons à améliorer leur infrastructure dans l'optique de l'évolutivité. Cela ne profite pas uniquement aux clients de Cloudflare, mais contribue également à un Internet meilleur, en exigeant des autorités de certification qu'elles traitent des volumes d'émissions de certificats plus élevés.

Et maintenant que Let's Encrypt raccourcit sa chaîne de confiance, nous allons ajouter une amélioration supplémentaire à notre pipeline – une amélioration qui garantira la meilleure compatibilité des appareils pour tous.

Prise en charge de tous les clients : anciens et modernes

Le changement à venir affectant Let's Encrypt empêchera les appareils anciens de transmettre des requêtes à des domaines ou des applications protégés par un certificat Let's Encrypt. Nous ne voulons pas couper l'accès à Internet de quelque partie du monde que ce soit, ce qui signifie que nous allons continuer à offrir à nos clients la meilleure compatibilité des appareils, malgré ce changement.

Grâce aux récentes améliorations, nous sommes en mesure de réduire notre dépendance à l'égard de Let's Encrypt, sans toutefois affecter la fiabilité ou la qualité de service de notre pipeline de certificats. Un cycle de vie de certificat (90 jours) avant la modification, nous allons commencer à transférer les certificats vers une autre autorité de certification, compatible avec les appareils concernés. Ainsi, nous atténuerons les répercussions sans action requise de la part de nos clients. Les seuls clients qui continueront à utiliser Let's Encrypt sont ceux qui ont spécifiquement choisi Let's Encrypt comme autorité de certification.

Ce que vous pouvez attendre du futur changement affectant Let's Encrypt

La chaîne de certificats à signature croisée de Let's Encrypt expirera le 30 septembre 2024. Bien que Let's Encrypt propose d'arrêter d'émettre des certificats depuis cette chaîne le 6 juin 2024, Cloudflare continuera à servir la chaîne de certificats à signature croisée pour tous les certificats Let's Encrypt jusqu'au 9 septembre 2024.

90 jours (soit un cycle de vie de certificat) avant le changement, nous allons commencer à transférer les certificats Let's Encrypt vers une autre autorité de certification. Nous effectuerons cette modification à tous les produits pour lesquels Cloudflare est responsable de la sélection de l'autorité de certification ; cette modification sera donc mise en œuvre automatiquement pour les clients utilisant Universal SSL et SSL for SaaS avec le choix « Default CA » (autorité de certification par défaut).

Tous les clients qui ont spécifiquement choisi Let's Encrypt comme autorité de certification recevront une notification par e-mail avec une liste de leurs certificats Let's Encrypt, ainsi que des informations indiquant si nous observons ou non des requêtes transmises à ces noms d'hôtes depuis des appareils anciens.

Après le 9 septembre 2024, Cloudflare diffusera tous les certificats Let's Encrypt avec la chaîne ISRG Root X1. Voici ce à quoi vous pouvez vous attendre, en fonction du produit de certificat que vous utilisez :

Universal SSL

Avec Universal SSL, Cloudflare choisit l'autorité de certification utilisée pour le certificat du domaine. Cette approche nous donne la possibilité de choisir le meilleur certificat pour nos clients. Si vous utilisez Universal SSL, vous n'avez aucune modification à apporter pour vous préparer à ce changement ; Cloudflare modifiera automatiquement votre certificat afin d'utiliser une autorité de certification plus compatible.

Certificats avancés

Avec Advanced Certificate Manager, les clients choisissent spécifiquement l'autorité de certification qu'ils souhaitent utiliser. Si Let's Encrypt a été spécifiquement choisi comme autorité de certification pour un certificat donné, nous respecterons ce choix, car les clients peuvent avoir spécifiquement choisi cette autorité de certification en raison d'exigences internes, ou parce qu'ils ont mis en place l'association de certificat (« certificate pinning »), ce que nous déconseillons fortement.

Si nous constatons qu'un domaine utilisant un certificat avancé émis par Let's Encrypt sera affecté par le changement, nous enverrons des notifications par e-mail afin d'informer ces clients sur les certificats qui utilisent Let's Encrypt comme autorité de certification et d'indiquer si ces domaines reçoivent ou non des requêtes de clients qui seront affectés par le changement. Les clients auront la responsabilité de changer d'autorité de certification et de choisir un autre fournisseur, s'ils choisissent de le faire.

SSL pour SaaS

Avec SSL for SaaS, les clients disposent de deux choix : utiliser une autorité de certification par défaut, ce qui signifie qu'il incombera à Cloudflare de choisir l'autorité émettrice, ou spécifier l'autorité de certification qu'ils souhaitent utiliser.

Si vous confiez à Cloudflare le choix de l'autorité de certification, nous utiliserons automatiquement une autorité de certification offrant une meilleure compatibilité avec les appareils.

Si vous spécifiez une autorité de certification donnée pour vos noms d'hôte personnalisés, nous respecterons ce choix. Nous enverrons un e-mail aux fournisseurs et plateformes SaaS, afin de les informer sur les noms d'hôte personnalisés qui reçoivent des requêtes provenant d'appareils anciens. Les clients auront la responsabilité de changer d'autorité de certification et de choisir un autre fournisseur, s'ils choisissent de le faire.

Certificats personnalisés

Si vous effectuez une intégration directe avec Let's Encrypt et vous utilisez des certificats personnalisés pour transférer vos certificats Let's Encrypt vers Cloudflare, vos certificats seront groupés avec la chaîne de certificats à signature croisée, pour autant que vous choisissez la méthode de groupement « compatible » ou « modern » (moderne) et que vous transfériez ces certificats avant le 9 septembre 2024. Après le 9 septembre, nous grouperons tous les certificats Let's Encrypt avec la chaîne ISRG Root X1. Avec la méthode de regroupement « user-defined » (défini par l'utilisateur), nous servons toujours la chaîne transférée vers Cloudflare. Si vous chargez des certificats Let's Encrypt avec cette méthode, vous devrez vous assurer que les certificats transférés après le 30 septembre 2024 (c'est-à-dire la date d'expiration de l'autorité de certification) contiennent la bonne chaîne de certificats.

De plus, si vous contrôlez le client qui se connecte à votre application, nous vous recommandons de mettre à jour le Trust Store afin d'inclure le certificat ISRG Root X1. Si vous utilisez l'association de certificat (« certificate pinning »), supprimez ou mettez à jour votre association. En règle générale, nous déconseillons à tous les clients d'associer leurs certificats, car cette pratique entraîne habituellement des problèmes lors des renouvellements de certificats ou des changements d'autorité de certification.

Conclusion

Les normes Internet continueront d'évoluer et de s'améliorer. Tout en prenant en charge et en adoptant ces changements, nous devons également reconnaître qu'il est de notre responsabilité de préserver la présence en ligne des utilisateurs et de maintenir l'accès à Internet dans les régions du monde où les nouvelles technologies ne sont pas aisément disponibles. En utilisant Cloudflare, vous avez toujours la possibilité de choisir la configuration qui convient le mieux à votre application.

Pour plus d'informations concernant le changement, consultez notre documentation pour développeurs.

Nous protégeons des réseaux d'entreprise entiers, aidons nos clients à développer efficacement des applications à l'échelle d'Internet, accélérons tous les sites web ou applications Internet, repoussons les attaques DDoS, tenons les pirates informatiques à distance et pouvons vous accompagner dans votre parcours d'adoption de l'architecture Zero Trust.

Accédez à 1.1.1.1 depuis n'importe quel appareil pour commencer à utiliser notre application gratuite, qui rend votre navigation Internet plus rapide et plus sûre.

Pour en apprendre davantage sur notre mission, à savoir contribuer à bâtir un Internet meilleur, cliquez ici. Si vous cherchez de nouvelles perspectives professionnelles, consultez nos postes vacants.
SécuritéApplication ServicesTLSSSLCertificate Authority (FR)Deep Dive (FR)

Suivre sur X

Dina Kozlov|@dinasaur_404
Cloudflare|@cloudflare

Publications associées

08 octobre 2024 à 13:00

Cloudflare acquires Kivera to add simple, preventive cloud security to Cloudflare One

The acquisition and integration of Kivera broadens the scope of Cloudflare’s SASE platform beyond just apps, incorporating increased cloud security through proactive configuration management of cloud services. ...