Présentation : certificats de secours

Chez Cloudflare, nous sommes fiers d'offrir à chaque client la possibilité d'obtenir gratuitement un certificat TLS pour ses applications Internet. Aujourd'hui, nous sommes en charge de la gestion du cycle de vie de près de 45 millions de certificats, depuis l'émission jusqu'au déploiement et au renouvellement. Tandis que nous bâtissons la plateforme la plus résiliente et la plus robuste, nous la souhaitons plus évolutive et plus résistante face aux événements qu'il nous est impossible de prévoir.

Il importe que les événements qui nous obligent à réémettre des certificats pour nos clients tels que les compromissions de clé, les vulnérabilités et les révocations en masse donnent lieu à une action immédiate. Faute de quoi, les clients évoluent dans l'insécurité et sont mis hors ligne. Lorsqu'il se produit un de ces événements, nous voulons être prêts à en atténuer les effets de manière immédiate. Mais comment ?

Avec un certificat de secours prêt à être déployé, placé dans une clé privée différente, et émis par une autre autorité de certification que le certificat primaire que nous servons.

Cloudflare réémet des certificats chaque jour, nous appelons cela un renouvellement de certificat. Les certificats ayant une date d'expiration, lorsque Cloudflare voit qu'un certificat va bientôt expirer, nous lançons un nouvel ordre de renouvellement de certificat. Ainsi, au moment où le certificat expire, nous avons déjà déployé un certificat mis à jour et prêt à être utilisé pour la terminaison TLS.

Malheureusement, à la date d'expiration, tous les renouvellements de certificat n'ont pas été lancés. Il arrive que des événements impossibles à anticiper tels que des compromissions de clé conduisent à des renouvellements de certificats. Cela tient au fait qu'une nouvelle clé doit être émise, et il en va de même pour le certificat correspondant.

On parle de compromission de clé lorsqu'une personne ou un système non autorisé obtient une clé privée qui sert à chiffrer et déchiffrer des informations secrètes ; c'est le pire des cauchemars pour le personnel de sécurité. Les compromissions de clé peuvent provenir d'une vulnérabilité, Heartbleed par exemple, au cours de laquelle un bug présent dans un système peut engendrer une fuite de clé privée. Elles peuvent également être le résultat d'actions malveillantes, comme celle d'un employé malintentionné qui accéderait à des informations pour lesquelles il ne dispose pas d'autorisation. Dans le cas d'une compromission de clé, il est absolument impératif que (1) de nouvelles clés privées soient immédiatement émises, (2) de nouveaux certificats soient déployés et (3) que les anciens certificats soient révoqués.

En 2014, la vulnérabilité Heartbleed a été mise à jour. Elle permettait aux attaquants d'extraire la clé privée du certificat TLS de n'importe quel serveur exécutant la version affectée d'OpenSSL, une bibliothèque populaire de chiffrement. Nous avons apporté un correctif pour le bug puis, par souci de précaution, nous avons rapidement renouvelé les clés privées et les certificats TLS de tous nos clients, quand bien même aucune de nos clés n'avait fait l'objet de fuites. En agissant rapidement, Cloudflare a évité à nos clients de voir leurs données exposées.

Heartbleed a suscité une prise de conscience. À l'époque, l'étendue de Cloudflare était encore moindre. À l'échelle d'aujourd'hui, avec une vulnérabilité de la sorte, il nous faudrait non pas des heures, mais des semaines pour renouveler les certificats de l'ensemble de nos clients.

Désormais, avec les certificats de secours, nous n'avons plus à nous soucier du lancement d'un renouvellement en masse dans un temps limité. Au lieu de cela, les clients disposent déjà d'un certificat qu'ils sont en mesure de déployer de manière instantanée. Qui plus est, le certificat de secours sera également intégré dans une clé différente de celle du certificat primaire, l'empêchant ainsi d'être affecté par une compromission de clé.

Les compromissions des clés sont l'une des principales raisons pour lesquelles il est nécessaire de renouveler des certificats à grande échelle. Toutefois, d'autres événements peuvent également imposer un renouvellement immédiat, c'est le cas notamment des révocations en masse par des autorités de certification.

Aujourd’hui, le CA/B Forum (Certificate Authority/Browser Forum) est l'organisme qui définit les règles et les normes pour les certificats. Une des exigences fondamentales établies par le CA/B Forum stipule que les autorités de certifications ont l'obligation de révoquer les certificats dont les clés sont susceptibles d'avoir été compromises dans les 24 heures. Pour les alertes moins urgentes, concernant par exemple une mauvaise utilisation d'un certificat ou une infraction à une politique de certificats d'une autorité de certification, la révocation doit intervenir dans les cinq jours. Dans les deux scénarios, les certificats seront révoqués par l'autorité de certification dans un délai bref, et un renouvellement immédiat des certificats est exigé.

Si les révocations en masse sont rarement lancées par les autorités de certification, c'est arrivé à plusieurs reprises au cours des quelques dernières années. Récemment, Let’s Encrypt a dû révoquer environ 2,7 millions de certificats après la découverte d'une non-conformité dans la mise en œuvre d'une vérification DCV. À cette occasion, les clients Cloudflare n'ont eu aucune conséquence à subir.

Un autre jour, une des autorités de certification auxquelles nous faisons appel a découvert qu'elle renouvelait les certificats sur la base de jetons de validation qui n'étaient pas conformes aux normes du CA/B Forum. Elle a donc été obligée de lancer une révocation en masse, avec une incidence sur environ cinq mille domaines gérés par Cloudflare. Nous avons collaboré avec nos clients et l'autorité de certification afin d'émettre de nouveaux certificats avant la révocation et d'en minimaliser les répercussions.

Nous en sommes bien conscients, les erreurs sont toujours possibles, et nous avons eu la chance qu'au moment où ces problèmes se sont produits nos équipes techniques ont pu procéder rapidement à une atténuation et les clients n'en ont pas été affectés. Mais ce n'est pas tout : nos systèmes ont besoin d'être parés pour l'avenir de sorte que la révocation de 45 millions de certificats puisse avoir sans que nos clients n'aient à en pâtir. Avec les certificats de secours, nous sommes prêts pour un renouvellement en masse, quelle qu'en soit l'échelle.

Dans un souci de résilience aux révocations en masse déclenchées par nos autorités de certification, nous allons émettre chaque certificat de secours depuis une autorité de certification différente de celle ayant émis le certificat primaire. Cela ajoutera une couche de protection au cas où une de nos autorités de certification devrait invoquer une révocation en masse, ce qui une fois déclenchée constitue véritablement une bombe à retardement.

Lorsque la vulnérabilité Heartbleed a été mise à jour, nous avons dû réémettre environ 100 000 certificats. À cette époque, ce n'était pas un problème pour Cloudflare. À l'heure actuelle, nous sommes responsables de dix millions de certificats. Même si nos systèmes sont capables de gérer cette échelle, nous dépendons également de nos partenaires d'autorité de certification pour y parvenir. En cas d'urgence, nous ne souhaitons pas être dépendants de systèmes que nous ne contrôlons pas. C'est pourquoi il est important pour nous que les certificats soient émis à l'avance ; ainsi, lorsque la catastrophe survient, la seule chose dont nous avons à nous préoccuper, c'est le déploiement des certificats de secours.

Une autre difficulté liée au renouvellement des certificats réside dans la validation de contrôle de domaine (DCV). La DCV est une vérification qui permet de valider la propriété d'un domaine avant qu'une autorité de certification ne puisse émettre un certificat le concernant. Lorsque les clients rejoignent Cloudflare, ils peuvent s'en remettre à Cloudflare pour être leur fournisseur DNS, ou ils peuvent décider d'utiliser Cloudflare comme un proxy tout en conservant leur fournisseur DNS actuel.

Lorsque Cloudflare agit en tant que fournisseur DNS pour un domaine, nous pouvons ajouter des enregistrements de validation de contrôle de domaine (DCV) au nom de notre client. La procédure d'émission et de renouvellement du certificat s'en trouve grandement simplifiée.

Les domaines qui n'utilisent pas Cloudflare comme fournisseur DNS (nous les appelons les zones partielles) doivent compter sur d'autres méthodes pour effectuer la DCV. Lorsque ces domaines mettent leur trafic en proxy à travers nous, nous pouvons réaliser la DCV HTTP en leur nom, en fournissant le jeton DCV HTTP depuis notre périphérie. Toutefois, les clients qui souhaitent que leur certificat soit émis avant de mettre leur trafic en proxy doivent réaliser manuellement la DCV. Si un événement obligeait Cloudflare à renouveler des milliers ou des millions de certificats, sans qu'il soit possible de réaliser les DCV au nom du client, une intervention manuelle serait nécessaire. La validation DCV n'est pas une tâche complexe, toutefois, nous ne souhaitons pas être dépendant de nos clients en situation d'urgence, tandis qu'ils n'ont que très peu de temps pour agir et que les risques encourus sont grands.

C'est là que les certificats de secours entrent en jeu. Dorénavant, chaque émission de certificat déclenchera deux commandes : une pour un certificat émanant d'une autorité de certification primaire, et une pour le certificat de secours. Dans les cas où nous pouvons réaliser la DCV au nom du client, nous procèderons ainsi pour les deux autorités de certification.

Aujourd'hui nous n'émettons des certificats de secours que pour les domaines pour lesquels Cloudflare est le fournisseur DNS de référence. À l'avenir, nous commanderons des certificats de secours pour les zones partielles. Cela signifie que pour les certificats de secours pour lesquels nous ne sommes pas en mesure d'effectuer la DCV, nous remettrons aux clients les enregistrements DCV correspondants pour l'émission du certificat.

Nous sommes heureux d'annoncer que Cloudflare a commencé à déployer des certificats de secours dans des commandes de certificats universels pour les clients des offres gratuites qui utilisent Cloudflare comme fournisseur DNS de référence. Nous avons progressivement augmenté le nombre de commandes de certificats de secours et au cours des prochaines semaines, nous prévoyons d'intégrer un certificat de secours à chaque commande émise pour un compte gratuit, pro ou business ; celui-ci se trouvera dans une clé différente et sera émis depuis une autorité de certification différente de celle du certificat primaire.

À la fin du mois d'avril, nous commencerons à émettre des certificats de secours pour nos clients de l'offre Enterprise. Si vous êtes un client Enterprise et que vous avez des questions concernant les certificats de secours, contactez l'équipe chargée de votre compte.

Aujourd'hui, les certificats universels représentent 72 % des certificats de notre pipeline. Nous souhaitons cependant une couverture totale ! C'est pourquoi notre équipe va continuer à faire évoluer notre pipeline de certificats de secours pour prendre en charge les certificats avancés et les certificats SSL pour SaaS. À l'avenir, nous émettrons également des certificats de secours pour les certificats que nos clients transfèrent eux-mêmes, afin qu'ils disposent d'une sauvegarde fiable.

Par ailleurs, nous allons continuer d'améliorer notre pipeline pour rendre le déploiement des certificats de secours instantanés, afin que nos clients restent en sécurité et en ligne pendant les urgences.Chez Cloudflare, nous avons pour mission de bâtir un Internet meilleur. Avec les certificats de secours, nous contribuons à la mise en place d'un internet sécurisé et fiable, prêt pour n'importe quelle catastrophe. Vous souhaitez nous aider ? Nous recrutons.