Cloudflare wil zelf CA worden tegen de concentratie van gratis CA's

Cloudflare leunt al jaren op 16 publieke partner-CA's zonder ooit zelf een publiek vertrouwd certificaat te hebben uitgegeven. Nu wil het er zelf een worden, en het interessante zit in het ontwerp: klassieke certificaten en Merkle Tree Certificates onder één CA, met foutbeheersing vanaf het begin ingebouwd.

Een afnemer van certificaten wordt een uitgever #

De meeste infrastructuurbedrijven blijven aan één kant van de certificaatrelatie. Ze vragen certificaten aan, installeren ze en klagen als een CA een incident heeft. Cloudflare stond stevig aan de kant van de afnemers. Naar eigen zeggen heeft het nooit zelf één publiek vertrouwd certificaat uitgegeven.

Dat staat op het punt te veranderen, of Cloudflare zegt in elk geval dat het dat van plan is. Het bedrijf maakt bekend dat het een publieke certificeringsinstantie wil worden. De aankondiging is voorzichtig over waar het nu staat, en dit artikel moet dat ook zijn. Cloudflare geeft nog geen certificaten uit. Alles aan het gedrag van de dienst, van de ACME-interface tot de vernieuwingsregels en de ondersteuning van Merkle Tree Certificates, is een voornemen en geen beschrijving van een draaiend systeem.

Wat de aankondiging geloofwaardig maakt, is niet de ambitie maar het voorbereidende werk dat al zichtbaar is. Cloudflare heeft opname aangevraagd in de rootprogramma's van Chrome, Apple, Microsoft en Mozilla. Het zegt het aanvraag- en goedkeuringsproces te doorlopen bij elk van de centrale rootsleutelprogramma's van het web, en het wijst erop dat die processen openbaar verlopen. Iedereen kan in principe volgen of de aanvraag slaagt.

Waarom Cloudflare de vraag kan stellen #

Cloudflares argument voor een eigen CA begint bij zijn positie als klant. Het staat voor meer dan 20 procent van het wereldwijde internetverzoekverkeer. Het termineert TLS voor miljoenen domeinen en is afhankelijk van miljoenen certificaten per jaar. Via Universal SSL levert het certificaatpakketten aan zijn klanten, en het neemt ook certificaten af van veel verschillende CA's om zijn eigen systemen en interne processen te draaien.

Om de diensten van klanten in de lucht te houden, betrekt Cloudflare die certificaten via meerdere CA's, met primaire en reservepaden zodat diensten blijven werken bij storingen van een CA en bij intrekkingen. Het netwerk van publieke partner-CA's waarop het al vele jaren leunt, telt er 16.

Het reservemechanisme verdient een nadere blik, omdat het laat zien hoe Cloudflare over falen denkt. Elk Universal SSL-certificaat wordt al geleverd met een reservecertificaat, beveiligd met een aparte sleutel en uitgegeven door een andere instantie. Wordt het primaire certificaat ooit ingetrokken of gecompromitteerd, dan staat de reserve klaar om automatisch te worden uitgerold. Dat is een afdekking tegen het falen van één enkele CA, gebouwd vanaf de klantzijde van de relatie.

Het is ook een afdekking met een plafond. Je kunt alleen spreiden over de CA's die bestaan, en de bron stelt dat het aanbod aan capabele CA's dunner is dan het lijkt.

Het concentratieprobleem #

De cijfers achter dat argument zijn opvallend. Let's Encrypt geeft in de orde van tien miljoen certificaten per dag uit. Het bedient meer dan 500 miljoen sites en passeerde in 2025 de grens van vier miljard actieve certificaten. Dat zijn cijfers voor één gratis CA, en ze beschrijven een web waarvan de versleuteling zwaar op één organisatie leunt.

De bron trekt de voor de hand liggende conclusie, met een passend voorbehoud: als de dominante gratis certificeringsinstantie een slechte week had, zou een groot deel van het web geen vergelijkbaar gratis, geautomatiseerd alternatief hebben dat de last kan overnemen. Dat is een uitspraak over een hypothetisch geval, en Cloudflare presenteert die ook zo. Het beweert niet dat zo'n week heeft plaatsgevonden of eraan komt.

Toch is de logica makkelijk te volgen. Een gratis, geautomatiseerde CA is alleen een weerbaarheidsoptie als die bestaat vóór de noodsituatie. Cloudflares boodschap is dat het een tweede kan leveren, op schaal. Ik zou zeggen dat dit de sterkste commerciële en technische reden in de aankondiging is, en die hangt van geen van de meer speculatieve delen van het plan af. Een web met één dominante gratis CA en weinig anders is een web met een single point of failure, hoe goed die CA ook wordt beheerd.

Dimensie	Traditionele gratis geautomatiseerde CA (Let's Encrypt)	Voorgestelde publieke CA van Cloudflare
Strategie voor het vertrouwensanker	ISRG Root X1 / X2 (eigen roots, opgezet vanaf 2015)	Overgenomen GlobalSign-root (vertrouwd sinds 2012) + nieuwe root
Uitgifteprotocol	Standaard ACME (RFC 8555)	ACME met verplichte handhaving van ARI (RFC 9773)
Intrekkingsmodel	CRL / OCSP + massale noodvervanging bij abonnees	Gecoördineerd vervroegen van vernieuwing via ARI-endpoints
Post-kwantumpad	Hybride X.509-handtekeningen in evaluatie	Native Merkle Tree Certificates (MTC's) naast klassiek X.509
Schaal en initiële belasting	~10 mln certificaten per dag voor meer dan 500 mln sites	Customer Zero-validatie over meer dan 20% van het wereldwijde webverkeer

Een root kopen in plaats van erop te wachten #

De meest praktische beslissing in de aankondiging gaat over de root. Cloudflare zegt een definitieve overeenkomst te hebben getekend om een gevestigde, breed vertrouwde root van GlobalSign over te nemen. De bron geeft de reden direct: een gloednieuwe root is jarenlang niet breed bruikbaar. De bestaande GlobalSign-root wordt daarentegen sinds 2012 vertrouwd in browsers, besturingssystemen en apparaten.

Vertrouwen in een root groeit langzaam omdat het in apparaten is geïnstalleerd, en apparaten worden langzaam bijgewerkt. Een nieuwe root kan door elk programma zijn geaccepteerd en toch niet valideren op een oudere telefoon of een embedded systeem. Een root overnemen die al sinds 2012 in het veld zit, omzeilt die wachttijd, in elk geval zoals de bron het voorstelt.

Cloudflare laat de route van een nieuwe root niet helemaal los. Het dient ook een nieuwe root in voor opname in de rootsleutelprogramma's, die het beschrijft als gebouwd voor de richting die het ecosysteem op gaat, inclusief programma's die beginnen te begrenzen hoe oud een vertrouwde root mag zijn. Dat laatste detail herinnert er nuttig aan dat leeftijd twee kanten op werkt. De leeftijd van een vertrouwde root is een troef voor de dekking van apparaten, en sommige programma's bewegen naar grenzen aan hoe oud een vertrouwde root mag zijn. Zowel een overgenomen root als een nieuwe indiening beheren, lijkt een antwoord op die spanning, al legt de bron de redenering niet in die woorden uit.

Een ACME-first-dienst met voorwaarden #

Bij de adoptie worden veel CA-aankondigingen vaag. Cloudflare is concreet. Zijn publieke CA wordt ACME-first, wat betekent dat het het Automated Certificate Management Environment-protocol spreekt dat bestaande automatisering al gebruikt. De claim is dat iedereen die al naar een bestaande gratis CA wijst, kan overstappen naar de CA van Cloudflare door één directory-URL te wijzigen, zonder nieuwe tooling en zonder iets te herontwerpen. Dat is een plan, geen geteste migratieroute, en zo moet je het ook lezen. Maar een configuratiewijziging van één regel is het juiste doel, want migratiekosten houden mensen bij een standaardkeuze.

Het addertje is een eis waar de meeste ACME-gebruikers nog niet aan hoefden te voldoen. Cloudflare geeft alleen uit aan clients die ACME Renewal Information ondersteunen, kortweg ARI, gestandaardiseerd in RFC 9773. Abonnees moeten automatisering onderhouden die het vernieuwingsendpoint van Cloudflare bevraagt, handelt volgens de vernieuwingsvensters die Cloudflare publiceert, en aangeeft welk certificaat ze vervangt.

Dat is een stevige positie, en ik denk dat het de juiste is. Het roept ook een terechte vraag over adoptie op: een CA die alleen ARI-geschikte clients bedient, is smaller dan een die iedereen met een ACME-bibliotheek bedient. De bron zegt niet hoeveel clients daardoor vandaag buiten de boot vallen, dus ik ga niet gokken. Wat de bron wel zegt, is waarom Cloudflare die beperking wil.

Intrekken zonder sites plat te leggen #

Cloudflare zegt de afgelopen 16 jaar het een en ander te hebben waargenomen, en één waarneming stuurt dit ontwerp. Het heeft certificeringsinstanties gezien die klem zaten tussen tijdige intrekking en het online houden van de sites van hun abonnees.

Die spanning is reëel voor elke CA. Een certificaat snel intrekken beschermt het publiek, maar kan elke site platleggen die van dat certificaat afhangt als de abonnee het niet snel genoeg kan vervangen. Een CA die klem zit, trekt óf te laat in óf legt klanten plat.

ARI is het antwoord van Cloudflare. Als certificaten moeten worden uitgefaseerd, kan Cloudflare naar eigen zeggen de vernieuwingsvensters van de betrokken certificaten naar voren halen. Omdat abonnees verplicht zijn het vernieuwingsendpoint te bevragen en volgens de gepubliceerde vensters te handelen, kan de CA hen naar vervanging sturen voordat een harde intrekking ingaat. Dit mechanisme wordt beschreven als een vermogen dat Cloudflare wil hebben, niet als een dat het als CA heeft aangetoond. Toch klopt de logica: de bevragingsplicht bestaat zodat deze hefboom werkt.

Hetzelfde denken zie je in een breder ontwerpdoel. Cloudflare wil een certificeringsinstantie bouwen waarvan de betrouwbaarheid niet alleen afhangt van het vermijden van fouten, maar, zoals bij de rest van de producten van Cloudflare, van klein falen en het beperken van de impact van elk afzonderlijk probleem. Fouten vermijden is noodzakelijk voor een CA, en geen CA kan dat volmaakt beloven. Zo ontwerpen dat een fout beperkt blijft, is de eerlijkere technische houding.

Transparantie voorbij de audit #

Publieke CA's worden doorgaans beoordeeld op audits. De bron is duidelijk over hun grenzen: audits zijn momentopnamen en vertellen je dat een CA is geslaagd. Ze vertellen je niet wat de CA daarna op een willekeurige dinsdag doet.

Cloudflares antwoord is de toezegging reproduceerbare builds te publiceren van de software die certificaten ondertekent. Dat wordt gepresenteerd als een toezegging, niet als een afgerond resultaat. Reproduceerbare builds laten buitenstaanders controleren of het binaire bestand in het ondertekeningspad overeenkomt met de gepubliceerde broncode, en dat is een doorlopende eigenschap, wat een auditrapport niet is. Of dat volstaat, hangt af van wat Cloudflare daadwerkelijk publiceert en of anderen het controleren.

De tweede helft van de aankondiging: Merkle Tree Certificates #

Bij het post-kwantumdeel kijkt de aankondiging het verst vooruit. Cloudflare kondigt aan een van de eerste CA's te willen zijn die post-kwantumcertificaten levert, en is van plan zijn eerste Merkle Tree Certificates in het eerste kwartaal van 2027 uit te geven. Een andere passage in de bron zegt dat de eerste MTC's begin 2027 worden verwacht. Beide zijn plannen.

De bron beschrijft MTC's als een nieuwe en veel compactere manier om publiek vertrouwde certificaten te leveren. Die formulering is een beschrijving, en de bron geeft in de passages waar ik mee werk geen metingen, dus ik kan niet zeggen hoeveel compacter. Cloudflare zegt bij de IETF het op standaarden gebaseerde voorstel voor MTC's te steunen. Het meldt ook dat Chrome eerder dit jaar MTC's heeft aangewezen als de voorkeursroute voor post-kwantumauthenticatie. Dat is een aangetoonde gebeurtenis, en die telt, want de uitgesproken voorkeur van een browsermaker maakt van een voorstel iets waarop een CA kan plannen.

Cloudflare verwacht geen plotselinge overgang. Het verwacht dat een groot deel van het internet nog vele jaren op klassieke certificaten en de bestaande WebPKI blijft vertrouwen. In die periode verwacht het dat MTC's een gestaag groeiend aandeel van de uitgifte gaan innemen. Dat zijn verwachtingen, en de bron benoemt ze ook zo.

Eén CA, één levenscyclus #

De architectuurkeuze die hieruit volgt, vind ik het meest overtuigend. De nieuwe CA is ontworpen om klassieke certificaten en Merkle Tree Certificates onder één CA te dragen, met één levenscyclus en één set garanties. Klanten kunnen dan overstappen in het tempo dat hun past en het web helpen de overgang te maken zonder harde omschakeling.

Het alternatief zijn twee parallelle CA's, twee sets procedures en op enig moment een gedwongen migratie. Een harde omschakeling is de riskantste manier om een certificaatecosysteem te veranderen, en het uitgesproken doel van de bron is die te vermijden. De formulering is voorzichtig, en terecht: het gaat om een ontwerpintentie voor een CA die nog niet uitgeeft.

Het past ook bij het beeld van de prikkels. Cloudflare zegt te verwachten dat het aantal certificaten waarvan het jaarlijks afhankelijk is, blijft groeien naarmate de maximale geldigheidsduur afneemt, agentische activiteit toeneemt en post-kwantumcertificaten mainstream worden. Meer certificaten, vaker uitgegeven, pleiten voor automatisering en voor een CA die vernieuwing als volwaardige operatie behandelt. Een systeem rond ARI en één levenscyclus is een redelijk antwoord op die verwachting, al is de verwachting zelf een prognose en geen meting.

Customer Zero #

Hoe test je een CA voordat het publiek erop vertrouwt? Cloudflares antwoord is zijn eigen eerste klant zijn. Het wordt Customer Zero voor de nieuwe CA en haar certificaten, zowel WebPKI als MTC. Het genoemde doel is ervoor te zorgen dat alle aspecten van de nieuwe systemen en processen aan de hoge interne normen van Cloudflare voldoen, en dat de infrastructuur van de CA op de schaal van Cloudflare wordt beproefd.

Gezien de eerdere cijfers is dat een veeleisende interne belasting: miljoenen certificaten per jaar, in een bedrijf dat voor meer dan 20 procent van het wereldwijde verzoekverkeer staat. Of de eerste bedrijfsjaren soepel verlopen, kunnen de claims ons niet vertellen. Wat ze wel laten zien, is een verstandige volgorde. Het bedrijf begint als zware gebruiker van wat het bouwt, met een geschiedenis van levering via meerdere CA's, reservepaden en 16 partner-CA's achter zich.

Het is goed om duidelijk te zijn over wat ontbreekt. Niets in de bron meldt uitgiftevolumes, foutpercentages, validatielatentie of een incidentgeschiedenis voor Cloudflares eigen CA, omdat zo'n geschiedenis er nog niet is. De aankondiging is een intentieverklaring, ondersteund door aanvragen, een overnameovereenkomst en een ontwerp. Een staat van dienst is het niet.

Waar je op moet letten #

Drie dingen bepalen of dit een betekenisvolle toevoeging aan de WebPKI wordt of slechts een interessante aankondiging.

Het eerste zijn de rootprogramma's. Cloudflare heeft zich aangemeld bij Chrome, Apple, Microsoft en Mozilla, en de processen zijn openbaar. Ze volgen is de meest directe manier om te zien hoe ver het plan is gekomen, en geen van de claims laat me de uitkomst voorspellen.

Het tweede is de ARI-eis. Een CA die op ondersteuning van RFC 9773 staat, gokt erop dat vernieuwingsautomatisering in haar hele abonneebestand kan worden doorgevoerd. Klopt die gok, dan kan Cloudflare vernieuwingsvensters naar voren halen wanneer certificaten moeten worden uitgefaseerd, en dat is het genoemde antwoord op het intrekkingsdilemma dat het heeft gezien. Klopt hij niet, dan verloopt de adoptie trager dan het verhaal van de migratie in één regel doet vermoeden.

Het derde is het eerste kwartaal van 2027. Dan plant Cloudflare zijn eerste Merkle Tree Certificates. De open vraag is hoe snel het gestaag groeiende aandeel dat het verwacht werkelijk groeit, gezien zijn eigen inschatting dat een groot deel van het internet nog vele jaren bij klassieke certificaten blijft. Het bedrijf heeft gezegd dat de overgang geen harde omschakeling zou moeten vergen. Het eerste kwartaal van 2027 wordt de eerste kans om te zien of één CA die beide soorten certificaten draagt, dat kan waarmaken.

Wat dit per sector betekent #

De komst van een geautomatiseerde publieke certificeringsinstantie met hoog volume vanuit een edge-infrastructuuraanbieder verandert het operationele risico en de PKI-planning in meerdere technische domeinen.

Cloudinfrastructuur en edge-netwerken #

Een publieke CA op edge-schaal draaien vermindert de externe afhankelijkheid van verificatie-API's en CRL's van derden. Door edge-terminatie via reverse proxy te koppelen aan geautomatiseerde ACME ARI-vernieuwingen kunnen infrastructuuraanbieders hun klanten afschermen van storingen bij certificeringsinstanties verderop in de keten.

Enterprise-PKI en DevOps-teams #

Organisaties die voor publieke endpoints op Let's Encrypt vertrouwen, krijgen een geloofwaardig, geautomatiseerd alternatief. De verplichte handhaving van RFC 9773 (ARI) betekent echter dat teams hun ACME-clients (Certbot, Lego, Caddy, Traefik) moeten controleren om zeker te weten dat ARI-ondersteuning actief is voordat ze van directory-endpoint wisselen.

Browsermakers en rootbeheer #

De rootprogramma's (Chrome, Mozilla, Apple, Microsoft) krijgen te maken met een groeiend ecosysteem van geautomatiseerde CA's met hoog volume. De tweesporenaanpak voor roots (een oudere root uit 2012 overnemen en tegelijk een moderne root indienen) laveert tussen browserbeleid dat de levensduur van rootcertificaten steeds verder beperkt en achterwaartse compatibiliteit voor oudere apparaten.

Conclusie #

Cloudflares stap om een publieke certificeringsinstantie te worden, pakt een echte structurele kwetsbaarheid in de moderne WebPKI aan: extreme concentratie in de gratis, geautomatiseerde uitgifte van certificaten. Door een gevestigde GlobalSign-root, strikte ARI-vernieuwingsautomatisering en een brug naar post-kwantum Merkle Tree Certificates te combineren, richt het ontwerp zich op operationele weerbaarheid in plaats van louter certificaatlevering. Het succes hangt af van de goedkeuringen van de rootprogramma's en van hoe snel clienttooling ARI-standaarden overneemt vóór de uitrol in 2027.

Veelgestelde vragen #

Kan ik mijn ACME-client vandaag al naar de CA van Cloudflare overzetten?

Nog niet. Cloudflare heeft zijn intentie aangekondigd, de overeenkomst voor de overname van de root getekend en aanvragen ingediend bij de grote rootprogramma's. Publieke uitgifte staat gepland na de goedkeuringen van de rootprogramma's.

Wat is ACME Renewal Information (ARI) en waarom doet het ertoe?

ARI (RFC 9773) is een uitbreiding van het ACME-protocol waarmee certificeringsinstanties abonnees kunnen laten weten wanneer een certificaat moet worden vernieuwd. Zo kunnen CA's vervroegde vernieuwingen vóór geplande intrekkingen soepel coördineren en storingen van sites voorkomen.

Hoe verschillen Merkle Tree Certificates (MTC's) van standaard X.509-certificaten?

MTC's vervangen traditionele individuele cryptografische handtekeningen door Merkle-inclusiebewijzen die verankerd zijn in een publiek verifieerbaar log. Dat verkleint de certificaatgrootte en de transmissie-overhead aanzienlijk, waardoor ze een voorkeurskandidaat zijn voor post-kwantum TLS-authenticatie.

Bronnen #

Cloudflare, (2026). Een certificeringsinstantie bouwen voor het hele internet ⧉. Cloudflare Blog.
IETF, (2024). RFC 9773: Automated Certificate Management Environment (ACME) Renewal Information (ARI) ⧉. IETF.
IETF, (2025). Merkle Tree Certificates voor TLS ⧉. IETF.
Chrome Root Program, (2026). Beleid en overwegingen voor post-kwantumauthenticatie ⧉. Chromium Projects.

Laatst herzien 2026-09-20.

Laatst herzien 2026-10-27.

Dit artikel herpubliceren

Cloudflare wil zelf CA worden tegen de concentratie van gratis CA's — Sebastien Rousseau

Cloudflare wil een publieke certificeringsinstantie worden: aanmelding bij de rootprogramma's, aankoop van een GlobalSign-root, verplichte ARI en Merkle-certificaten.

Dit artikel valt onder de licentie Creative Commons Attribution 4.0 International. Herpublicatie vereist attributie aan de canonieke URL.

Cloudflare wil zelf CA worden tegen de concentratie van gratis CA's — Sebastien Rousseau

Cloudflare wil een publieke certificeringsinstantie worden: aanmelding bij de rootprogramma's, aankoop van een GlobalSign-root, verplichte ARI en Merkle-certificaten.

Originally published at https://sebastienrousseau.com/nl/2026-09-20-cloudflare-wil-zelf-ca-worden-tegen/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER