Cloudflare veut devenir AC face à la concentration des AC gratuites

Cloudflare s'appuie depuis des années sur 16 AC publiques partenaires sans avoir jamais émis lui-même un certificat de confiance publique. Il entend désormais en devenir une, et l'intérêt tient à la conception : certificats classiques et Merkle Tree Certificates sous une même AC, avec un confinement des défaillances prévu dès le départ.

Un consommateur de certificats devient émetteur #

La plupart des entreprises d'infrastructure restent d'un seul côté de la relation de certification. Elles demandent des certificats, les installent et se plaignent quand une AC subit un incident. Cloudflare se trouvait résolument du côté des consommateurs. De son propre aveu, il n'a jamais émis lui-même un seul certificat de confiance publique.

Cela est sur le point de changer, ou du moins Cloudflare dit en avoir l'intention. L'entreprise annonce son intention de devenir une autorité de certification publique. L'annonce reste prudente sur l'état actuel des choses, et cet article doit l'être aussi. Cloudflare n'émet pas encore de certificats. Tout ce qui touche au comportement du service, de son interface ACME à ses règles de renouvellement en passant par la prise en charge des Merkle Tree Certificates, relève d'un projet et non de la description d'un système en production.

Ce qui rend l'annonce crédible, ce n'est pas l'ambition mais le travail préparatoire déjà visible. Cloudflare a demandé son inclusion dans les programmes racine de Chrome, Apple, Microsoft et Mozilla. Il dit mener le processus de candidature et d'approbation avec chacun des principaux programmes de clés racine du Web, et il souligne que ces processus se déroulent publiquement. Chacun peut, en principe, observer si la candidature aboutit.

Pourquoi Cloudflare est bien placé pour poser la question #

L'argument de Cloudflare en faveur d'une AC part de sa position de client. Il se situe en amont de plus de 20 pour cent du trafic mondial de requêtes Internet. Il termine le TLS pour des millions de domaines et dépend de millions de certificats par an. Il fournit des lots de certificats à ses clients via Universal SSL, et il consomme aussi des certificats de nombreuses AC différentes pour faire tourner ses propres systèmes et ses opérations internes.

Pour maintenir les services de ses clients, Cloudflare obtient ces certificats auprès de plusieurs AC, avec des chemins principaux et de secours afin que les services restent disponibles en cas de panne d'une AC ou de révocation. Le réseau d'AC publiques partenaires sur lequel il s'appuie depuis de nombreuses années en compte 16.

Le mécanisme de secours mérite qu'on s'y arrête, car il montre comment Cloudflare pense la défaillance. Chaque certificat Universal SSL est déjà livré avec un certificat de secours, protégé par une clé distincte et émis par une autre autorité. Si le certificat principal est un jour révoqué ou compromis, le secours est prêt à être déployé automatiquement. C'est une couverture contre la défaillance d'une AC isolée, construite du côté client de la relation.

C'est aussi une couverture qui a un plafond. On ne peut diversifier qu'entre les AC qui existent, et la source soutient que l'offre d'AC compétentes est plus mince qu'il n'y paraît.

Le problème de la concentration #

Les chiffres derrière cet argument sont frappants. Let's Encrypt émet de l'ordre de dix millions de certificats par jour. Il sert plus de 500 millions de sites et a dépassé quatre milliards de certificats actifs en 2025. Ce sont les chiffres d'une seule AC gratuite, et ils décrivent un Web dont le chiffrement repose largement sur une seule organisation.

La source en tire la conclusion évidente, avec une réserve appropriée : si l'autorité de certification gratuite dominante traversait une mauvaise semaine, une grande partie du Web n'aurait aucune solution gratuite et automatisée comparable prête à prendre le relais. C'est un énoncé hypothétique, et Cloudflare le présente comme tel. Il n'affirme pas qu'une telle semaine s'est produite, ni qu'elle approche.

La logique reste facile à suivre. Une AC gratuite et automatisée n'est une option de résilience que si elle existe avant l'urgence. L'argument de Cloudflare est qu'il peut en fournir une seconde à grande échelle. C'est à mon sens la raison commerciale et technique la plus solide de l'annonce, et elle ne dépend d'aucun des volets plus spéculatifs du projet. Un Web qui n'a qu'une AC gratuite dominante et peu d'autres choses est un Web avec un point de défaillance unique, quelle que soit la qualité des opérations de cette AC.

Dimension	AC gratuite et automatisée traditionnelle (Let's Encrypt)	AC publique Cloudflare proposée
Stratégie d'ancre de confiance	ISRG Root X1 / X2 (racines internes créées à partir de 2015)	Racine GlobalSign acquise (reconnue depuis 2012) + nouvelle racine
Protocole d'émission	ACME standard (RFC 8555)	ACME avec application obligatoire d'ARI (RFC 9773)
Modèle de révocation	CRL / OCSP + remplacement d'urgence en masse chez les abonnés	Avancement coordonné du renouvellement via les points de terminaison ARI
Voie post-quantique	Signatures X.509 hybrides à l'étude	Merkle Tree Certificates (MTC) natifs coexistant avec le X.509 classique
Échelle et charge initiale	~10 M de certificats par jour pour plus de 500 M de sites	Validation Customer Zero sur plus de 20 % du trafic Web mondial

Acheter une racine plutôt que l'attendre #

La décision la plus pragmatique de l'annonce concerne la racine. Cloudflare indique avoir signé un accord définitif pour acquérir auprès de GlobalSign une racine établie et largement reconnue. La source en donne directement la raison : une racine toute neuve n'est pas vraiment utile avant des années. La racine GlobalSign existante, à l'inverse, est reconnue par les navigateurs, les systèmes d'exploitation et les appareils depuis 2012.

La confiance dans une racine progresse lentement parce qu'elle est installée dans les appareils, et que les appareils se mettent à jour lentement. Une nouvelle racine peut être acceptée par tous les programmes et ne toujours pas être validée sur un téléphone ancien ou un système embarqué. Acquérir une racine déjà déployée depuis 2012 évite cette attente, du moins telle que la source présente les choses.

Cloudflare n'abandonne pas pour autant la voie d'une nouvelle racine. Il soumettra aussi une nouvelle racine aux programmes de clés racine, qu'il décrit comme conçue pour la direction que prend l'écosystème, y compris des programmes qui commencent à plafonner l'âge d'une racine de confiance. Ce dernier détail rappelle utilement que l'âge joue dans les deux sens. L'ancienneté d'une racine de confiance est un atout pour la couverture des appareils, et certains programmes s'orientent vers des limites d'âge pour les racines de confiance. Gérer à la fois une racine acquise et une nouvelle candidature ressemble à une réponse à cette tension, même si la source ne détaille pas le raisonnement en ces termes.

Un service ACME d'abord, avec des conditions #

L'adoption est le point où beaucoup d'annonces d'AC deviennent floues. Cloudflare est précis. Son AC publique sera d'abord ACME, c'est-à-dire qu'elle parle le protocole Automated Certificate Management Environment que l'automatisation existante utilise déjà. L'idée est que quiconque pointe déjà vers une AC gratuite existante peut passer à l'AC de Cloudflare en changeant une URL de répertoire, sans nouvel outil et sans rien réarchitecturer. C'est un projet, pas une voie de migration éprouvée, et il faut le lire comme tel. Mais une modification de configuration d'une ligne est la bonne cible, car c'est le coût de migration qui maintient les gens sur une option par défaut.

Le revers est une exigence que la plupart des utilisateurs d'ACME n'ont jamais eu à remplir. Cloudflare n'émettra que pour les clients qui prennent en charge ACME Renewal Information, ou ARI, normalisé dans la RFC 9773. Les abonnés doivent maintenir une automatisation qui interroge le point de terminaison de renouvellement de Cloudflare, agit selon les fenêtres de renouvellement que Cloudflare publie et identifie le certificat qu'elle remplace.

C'est une position ferme, et je pense que c'est la bonne. Elle soulève aussi une vraie question d'adoption : une AC qui ne sert que les clients compatibles ARI est plus restreinte qu'une AC qui sert quiconque dispose d'une bibliothèque ACME. La source ne dit pas combien de clients cela exclut aujourd'hui, je ne ferai donc pas de supposition. Ce qu'elle dit, c'est pourquoi Cloudflare veut cette contrainte.

Révoquer sans casser les sites #

Cloudflare indique avoir observé certaines choses au cours des 16 dernières années, et l'une de ces observations guide cette conception. Il a vu des autorités de certification prises entre une révocation rapide et le maintien en ligne des sites de leurs abonnés.

Cette tension est réelle pour toute AC. Révoquer rapidement un certificat protège le public, mais peut faire tomber tous les sites qui dépendent de ce certificat si l'abonné ne peut pas le remplacer assez vite. Une AC prise entre les deux révoque trop tard ou casse ses clients.

ARI est la réponse de Cloudflare. Lorsque des certificats doivent être retirés, Cloudflare dit pouvoir avancer les fenêtres de renouvellement des certificats concernés. Comme les abonnés sont tenus d'interroger le point de terminaison de renouvellement et d'agir selon les fenêtres publiées, l'AC peut les orienter vers un remplacement avant qu'une révocation brutale ne tombe. Ce mécanisme est décrit comme une capacité que Cloudflare entend avoir, et non comme une capacité qu'il a démontrée en tant qu'AC. La logique tient néanmoins : l'obligation d'interrogation existe pour que ce levier fonctionne.

La même réflexion apparaît dans un objectif de conception plus large. Cloudflare entend construire une autorité de certification dont la fiabilité dépend non seulement de l'absence d'erreurs mais, comme pour le reste des produits de Cloudflare, de défaillances limitées et de l'impact restreint de chaque incident. Éviter les erreurs est nécessaire pour une AC, et aucune AC ne peut le promettre parfaitement. Concevoir le système pour qu'une erreur reste contenue est la position d'ingénierie la plus honnête.

La transparence au-delà de l'audit #

Les AC publiques sont normalement jugées sur leurs audits. La source est franche sur leurs limites : les audits sont ponctuels et vous disent qu'une AC a réussi. Ils ne vous disent pas ce que fait l'AC un mardi quelconque par la suite.

La réponse de Cloudflare est d'annoncer qu'il publiera des builds reproductibles du logiciel qui signe les certificats. C'est présenté comme un engagement, pas comme un livrable achevé. Les builds reproductibles permettent à des tiers de vérifier que le binaire exécuté dans la chaîne de signature correspond au code source publié, ce qui est une propriété continue, ce qu'un rapport d'audit n'est pas. Que cela suffise dépendra de ce que Cloudflare publiera réellement, et de la volonté d'autres acteurs de le vérifier.

Le second volet de l'annonce : les Merkle Tree Certificates #

Le volet post-quantique est celui où l'annonce regarde le plus loin. Cloudflare annonce vouloir être l'une des premières AC à servir des certificats post-quantiques, et prévoit d'émettre ses premiers Merkle Tree Certificates au premier trimestre 2027. Un autre passage de la source indique que les premiers MTC sont attendus début 2027. Ce sont dans les deux cas des projets.

La source décrit les MTC comme une manière nouvelle et bien plus compacte de délivrer des certificats de confiance publique. Cette formulation est une description, et la source ne fournit pas de mesures dans les passages sur lesquels je m'appuie, je ne peux donc pas dire à quel point ils sont plus compacts. Cloudflare dit défendre la proposition normalisée des MTC à l'IETF. Il rapporte aussi que Chrome a désigné les MTC comme la voie privilégiée pour l'authentification post-quantique plus tôt cette année. Il s'agit là d'un fait avéré, et il compte, car la préférence affichée d'un éditeur de navigateur est ce qui transforme une proposition en quelque chose sur quoi une AC peut planifier.

Cloudflare ne s'attend pas à une transition soudaine. Il prévoit qu'une grande partie d'Internet continuera de s'appuyer sur les certificats classiques et la WebPKI existante pendant encore de nombreuses années. Sur cette période, il s'attend à ce que les MTC prennent une part de l'émission en croissance régulière. Ce sont des attentes, et la source les présente comme telles.

Une AC, un cycle de vie #

Le choix d'architecture qui en découle est celui que je trouve le plus convaincant. La nouvelle AC est conçue pour porter certificats classiques et Merkle Tree Certificates sous une même AC, avec un seul cycle de vie et un seul ensemble de garanties. Les clients peuvent alors adopter au rythme qui leur convient et aider le Web à franchir le cap sans bascule brutale.

L'autre option serait deux AC parallèles, deux jeux de procédures et une migration forcée à un moment donné. Une bascule brutale est la manière la plus risquée de faire évoluer un écosystème de certificats, et l'objectif affiché de la source est de l'éviter. La formulation est prudente, à juste titre : il s'agit d'une intention de conception pour une AC qui n'émet pas encore.

Cela s'accorde aussi avec la question des incitations. Cloudflare dit s'attendre à ce que le nombre de certificats dont il dépend chaque année continue de croître à mesure que les durées de validité maximales diminuent, que l'activité agentique augmente et que les certificats post-quantiques se généralisent. Plus de certificats, émis plus souvent, plaident pour l'automatisation et pour une AC qui traite le renouvellement comme une opération de premier plan. Un système construit autour d'ARI et d'un seul cycle de vie est une réponse raisonnable à cette attente, même si l'attente elle-même est une prévision et non une mesure.

Customer Zero #

Comment tester une AC avant que le public ne s'y fie ? La réponse de Cloudflare est d'être son propre premier client. Il sera le Customer Zero de la nouvelle AC et de ses certificats, WebPKI comme MTC. Le but affiché est de garantir que tous les aspects des nouveaux systèmes et processus respectent les exigences internes élevées de Cloudflare, et que l'infrastructure de l'AC soit éprouvée à l'échelle de Cloudflare.

Au vu des chiffres précédents, c'est une charge interne exigeante : des millions de certificats par an, dans une entreprise qui se situe en amont de plus de 20 pour cent du trafic mondial de requêtes. Les affirmations ne peuvent pas nous dire si les premières années d'exploitation se passeront bien. Elles montrent en revanche un ordre des opérations sensé. L'entreprise commence comme gros utilisateur de ce qu'elle construit, avec un historique d'approvisionnement multi-AC, des chemins de secours et 16 AC partenaires derrière elle.

Il faut dire clairement ce qui manque. Rien dans la source ne rapporte de volumes d'émission, de taux d'erreur, de latence de validation ou d'historique d'incidents pour l'AC de Cloudflare, parce qu'un tel historique n'existe pas encore. L'annonce est une déclaration d'intention appuyée par des candidatures, un accord d'acquisition et une conception. Ce n'est pas un bilan.

Ce qu'il faut surveiller #

Trois éléments décideront si cette initiative est un ajout significatif à la WebPKI ou simplement une annonce intéressante.

Le premier, ce sont les programmes racine. Cloudflare a déposé sa candidature auprès de Chrome, Apple, Microsoft et Mozilla, et les processus sont publics. Les suivre est le moyen le plus direct de voir où en est le projet, et aucune des affirmations ne me permet d'en prédire l'issue.

Le deuxième, c'est l'exigence ARI. Une AC qui impose la prise en charge de la RFC 9773 parie que l'automatisation du renouvellement peut être généralisée dans sa base d'abonnés. Si le pari est juste, il donne à Cloudflare la possibilité d'avancer les fenêtres de renouvellement quand des certificats doivent être retirés, ce qui est la réponse affichée au dilemme de la révocation qu'il a observé. S'il est faux, l'adoption sera plus lente que ne le laisse entendre le récit d'une migration en une ligne.

Le troisième, c'est le premier trimestre 2027. C'est la période où Cloudflare prévoit ses premiers Merkle Tree Certificates. La question ouverte est la vitesse à laquelle la part en croissance régulière qu'il anticipe progressera vraiment, compte tenu de sa propre conviction qu'une grande partie d'Internet restera sur les certificats classiques pendant encore de nombreuses années. L'entreprise a dit que le passage ne devrait pas nécessiter de bascule brutale. Le premier trimestre 2027 sera la première occasion de voir si une AC portant les deux types de certificats peut le rendre possible.

Ce que cela signifie par secteur #

L'arrivée d'une autorité de certification publique automatisée et à fort volume, issue d'un fournisseur d'infrastructure en périphérie, modifie le risque opérationnel et la planification PKI dans plusieurs domaines techniques.

Infrastructure cloud et réseaux en périphérie #

Exploiter une AC publique à l'échelle de la périphérie réduit la dépendance externe aux API de vérification et aux CRL de tiers. En couplant la terminaison en périphérie par proxy inverse aux renouvellements automatisés ACME ARI, les fournisseurs d'infrastructure peuvent protéger leurs clients contre les pannes des autorités de certification en amont.

PKI d'entreprise et équipes DevOps #

Les organisations qui s'appuient sur Let's Encrypt pour leurs points de terminaison publics disposent d'une alternative automatisée crédible. Cependant, l'application obligatoire de la RFC 9773 (ARI) impose aux équipes d'auditer leurs clients ACME (Certbot, Lego, Caddy, Traefik) pour s'assurer que la prise en charge d'ARI est active avant de changer de point de terminaison de répertoire.

Éditeurs de navigateurs et gouvernance des racines #

Les programmes racine (Chrome, Mozilla, Apple, Microsoft) font face à un écosystème croissant d'AC automatisées à fort volume. L'approche à double racine (acquérir une racine historique de 2012 tout en soumettant une racine moderne) compose avec des politiques de navigateurs qui restreignent de plus en plus la durée de vie des certificats racine, tout en préservant la compatibilité avec les appareils anciens.

Conclusion #

La décision de Cloudflare de devenir une autorité de certification publique s'attaque à une véritable vulnérabilité structurelle de la WebPKI moderne : l'extrême concentration de l'émission gratuite et automatisée de certificats. En combinant une racine GlobalSign établie, une automatisation stricte du renouvellement ARI et une passerelle vers les Merkle Tree Certificates post-quantiques, la conception vise la résilience opérationnelle plutôt que le simple approvisionnement en certificats. Le succès dépendra des approbations des programmes racine et de la rapidité avec laquelle les outils clients adopteront les normes ARI avant le déploiement de 2027.

Questions ? Réponses.

Puis-je basculer mon client ACME vers l'AC de Cloudflare dès aujourd'hui ?

Pas encore. Cloudflare a annoncé son intention, signé l'accord d'acquisition de la racine et déposé ses candidatures auprès des principaux programmes racine. L'émission publique doit être déployée après les approbations des programmes racine.

Qu'est-ce qu'ACME Renewal Information (ARI) et pourquoi est-ce important ?

ARI (RFC 9773) est une extension du protocole ACME qui permet aux autorités de certification d'indiquer aux abonnés quand un certificat doit être renouvelé. Les AC peuvent ainsi coordonner en douceur des renouvellements anticipés avant des révocations planifiées, ce qui évite les pannes de sites.

En quoi les Merkle Tree Certificates (MTC) diffèrent-ils des certificats X.509 standard ?

Les MTC remplacent les signatures cryptographiques individuelles traditionnelles par des preuves d'inclusion Merkle ancrées dans un journal vérifiable publiquement. Cela réduit sensiblement la taille des certificats et le surcoût de transmission, ce qui en fait un candidat privilégié pour l'authentification TLS post-quantique.

Références #

Cloudflare, (2026). Construire une autorité de certification pour tout Internet ⧉. Blog Cloudflare.
IETF, (2024). RFC 9773 : Automated Certificate Management Environment (ACME) Renewal Information (ARI) ⧉. IETF.
IETF, (2025). Merkle Tree Certificates pour TLS ⧉. IETF.
Chrome Root Program, (2026). Politique et considérations sur l'authentification post-quantique ⧉. Chromium Projects.

Dernière révision 2026-09-20.

Dernière révision 2026-10-27.

Republier cet article

Cloudflare veut devenir AC face à la concentration des AC gratuites — Sebastien Rousseau

Cloudflare veut devenir une autorité de certification publique : candidature aux programmes racine, rachat d'une racine GlobalSign, ARI obligatoire et certificats Merkle.

Cet article est sous licence Creative Commons Attribution 4.0 International. La republication nécessite l'attribution à l'URL canonique.

Cloudflare veut devenir AC face à la concentration des AC gratuites — Sebastien Rousseau

Cloudflare veut devenir une autorité de certification publique : candidature aux programmes racine, rachat d'une racine GlobalSign, ARI obligatoire et certificats Merkle.

Originally published at https://sebastienrousseau.com/fr/2026-09-20-cloudflare-veut-devenir-ac-face-concentration/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FONDATEUR · INGÉNIEUR