Cloudflares egna certifikat ska motverka koncentrationen av gratis-CA

Cloudflare har i åratal förlitat sig på 16 offentliga partner-CA utan att själv utfärda ett enda offentligt betrott certifikat. Nu vill bolaget bli en egen CA, och det intressanta är utformningen: klassiska certifikat och Merkle Tree Certificates under en och samma CA, med felbegränsning inbyggd från början.

En certifikatkonsument blir certifikatutfärdare #

De flesta infrastrukturbolag håller sig på ena sidan av certifikatrelationen. De beställer certifikat, installerar dem och klagar när en CA har en incident. Cloudflare har stått stadigt på den konsumerande sidan. Enligt egen uppgift har bolaget aldrig själv utfärdat ett enda offentligt betrott certifikat.

Det ska snart ändras, eller åtminstone säger Cloudflare att det är avsikten. Bolaget meddelar sin avsikt att bli en offentlig certifikatutfärdare. Tillkännagivandet är noga med var saker står i dag, och det bör den här artikeln också vara. Cloudflare utfärdar inga certifikat ännu. Allt om tjänstens beteende, från dess ACME-gränssnitt till dess förnyelseregler och dess stöd för Merkle Tree Certificates, är en plan snarare än en beskrivning av ett system i drift.

Det som gör tillkännagivandet trovärdigt är inte ambitionen utan det grundarbete som redan syns. Cloudflare har ansökt om att tas upp i rotprogrammen hos Chrome, Apple, Microsoft och Mozilla. Bolaget säger att det arbetar sig igenom ansöknings- och godkännandeprocessen med vart och ett av webbens centrala rotnyckelprogram, och det påpekar att dessa processer sker öppet. Vem som helst kan i princip följa om ansökan lyckas.

Varför Cloudflare har läget att ställa frågan #

Cloudflares argument för att bygga en CA börjar med bolagets ställning som kund. Det står framför mer än 20 procent av den globala trafiken av förfrågningar på internet. Det avslutar TLS för miljontals domäner och förlitar sig på miljontals certifikat om året. Det tillhandahåller certifikatpaket via Universal SSL åt sina kunder, och det använder också certifikat från många olika CA för att driva sina egna system och sin interna verksamhet.

För att hålla kundtjänsterna uppe tar Cloudflare fram dessa certifikat via flera CA, med primära vägar och reservvägar så att kundtjänsterna förblir tillgängliga genom CA-avbrott och återkallelser. Nätverket av offentliga partner-CA som bolaget har förlitat sig på i många år omfattar 16.

Reservmekanismen förtjänar en närmare titt, eftersom den visar hur Cloudflare tänker kring fel. Varje Universal SSL-certifikat levereras redan med ett reservcertifikat, med en separat nyckel och utfärdat av en annan utfärdare. Om det primära någonsin återkallas eller komprometteras står reserven redo att driftsättas automatiskt. Det är en gardering mot att en enskild CA går fel, byggd från kundens sida av relationen.

Det är också en gardering med ett tak. Man kan bara sprida sig över de CA som finns, och källan hävdar att utbudet av kapabla CA är tunnare än det ser ut.

Koncentrationsproblemet #

Siffrorna bakom det argumentet är slående. Let's Encrypt utfärdar i storleksordningen tio miljoner certifikat om dagen. Den betjänar mer än 500 miljoner webbplatser och passerade fyra miljarder aktiva certifikat 2025. Det är siffror för en enda gratis CA, och de beskriver en webb vars kryptering lutar sig tungt mot en organisation.

Källan drar den uppenbara slutsatsen, med en reservation som är på sin plats: om den dominerande gratis certifikatutfärdaren hade en dålig vecka skulle stora delar av webben inte ha något jämförbart gratis, automatiserat alternativ redo att ta lasten. Det är ett påstående om ett hypotetiskt läge, och Cloudflare presenterar det som ett sådant. Bolaget påstår inte att en sådan vecka har inträffat, eller att en är på väg.

Ändå är logiken lätt att följa. En gratis, automatiserad CA är bara ett alternativ för motståndskraft om den finns innan nödläget. Cloudflares budskap är att bolaget kan erbjuda en andra i stor skala. Jag skulle hävda att det är det starkaste kommersiella och tekniska skälet i tillkännagivandet, och det beror inte på någon av planens mer spekulativa delar. En webb som har en dominerande gratis CA och lite annat är en webb med en enda felpunkt, oavsett hur väl den CA:n sköts.

Dimension	Traditionell gratis automatiserad CA (Let's Encrypt)	Föreslagen offentlig CA från Cloudflare
Strategi för förtroendeankare	ISRG Root X1 / X2 (egna rötter etablerade 2015 och senare)	Förvärvad GlobalSign-rot (betrodd sedan 2012) + ny rot
Utfärdandeprotokoll	Standard-ACME (RFC 8555)	ACME med obligatorisk tillämpning av ARI (RFC 9773)
Modell för återkallelse	CRL / OCSP + nödutbyte av abonnenter i stor skala	Samordnat tidigarelagd förnyelse via ARI-slutpunkter
Väg mot postkvant	Hybrida X.509-signaturer under utvärdering	Inbyggda Merkle Tree Certificates (MTC) som samexisterar med klassisk X.509
Skala och första arbetslast	~10 milj. certifikat/dag över 500 milj.+ webbplatser	Validering med Cloudflare som kund noll över 20 %+ av den globala webbtrafiken

Att köpa en rot i stället för att vänta på en #

Det mest praktiska beslutet i tillkännagivandet gäller roten. Cloudflare säger att bolaget har tecknat ett slutgiltigt avtal om att förvärva en etablerad, brett betrodd rot från GlobalSign. Källan ger skälet rakt ut: en helt ny rot är inte allmänt användbar på flera år. Den befintliga GlobalSign-roten har däremot varit betrodd i webbläsare, operativsystem och enheter sedan 2012.

Förtroende för en rot går långsamt eftersom roten installeras i enheter, och enheter uppdateras långsamt. En ny rot kan godkännas av alla program och ändå inte valideras på en äldre telefon eller i ett inbyggt system. Att förvärva en rot som redan har funnits ute sedan 2012 kringgår den väntan, åtminstone så som källan ramar in det.

Cloudflare överger inte vägen med en ny rot helt. Bolaget kommer också att skicka in en ny rot för upptagning i rotnyckelprogrammen, som det beskriver som byggd för vart ekosystemet är på väg, inklusive program som börjar sätta tak för hur gammal en betrodd rot får vara. Den sista detaljen är en nyttig påminnelse om att ålder skär åt båda hållen. En betrodd rots ålder är en tillgång för täckningen av enheter, och vissa program rör sig mot gränser för hur gammal en betrodd rot får vara. Att driva både en förvärvad rot och en ny ansökan ser ut som ett svar på den spänningen, även om källan inte formulerar resonemanget i de termerna.

En ACME-först-tjänst med villkor #

Det är vid införandet som många CA-tillkännagivanden blir vaga. Cloudflare är konkret. Bolagets offentliga CA blir ACME-först, vilket betyder att den talar protokollet Automated Certificate Management Environment som befintlig automatisering redan använder. Påståendet är att den som redan pekar på en befintlig gratis CA kan flytta till Cloudflares CA genom att byta en katalog-URL, utan nya verktyg och utan något att bygga om. Det är en plan, inte en testad migreringsväg, och den bör läsas som en sådan. Men en konfigurationsändring på en rad är rätt mål, eftersom kostnaden för att migrera är det som håller folk kvar vid ett standardval.

Haken är ett krav som de flesta ACME-användare inte har behövt uppfylla. Cloudflare kommer bara att utfärda till klienter som stöder ACME Renewal Information, eller ARI, som är standardiserat i RFC 9773. Abonnenterna måste underhålla automatisering som frågar Cloudflares förnyelseslutpunkt, agerar på de förnyelsefönster som Cloudflare publicerar och anger vilket certifikat den ersätter.

Det är en fast hållning, och jag tror att den är rätt. Den väcker också en rimlig fråga om införandet: en CA som bara betjänar ARI-kapabla klienter är smalare än en som betjänar alla som har ett ACME-bibliotek. Källan säger inte hur många klienter det utesluter i dag, så jag gissar inte. Vad den säger är varför Cloudflare vill ha begränsningen.

Återkallelse utan att sajter går sönder #

Cloudflare uppger att bolaget har iakttagit saker under de senaste 16 åren, och en iakttagelse styr den här utformningen. Det har sett certifikatutfärdare fastna mellan snabb återkallelse och att hålla abonnenternas webbplatser uppe.

Den spänningen är verklig för varje CA. Att återkalla ett certifikat snabbt skyddar allmänheten, men det kan slå ut varje webbplats som är beroende av certifikatet, om abonnenten inte kan ersätta det tillräckligt snabbt. En CA som hamnar mitt emellan återkallar antingen sent eller förstör för kunderna.

ARI är Cloudflares svar. När certifikat behöver tas ur bruk säger Cloudflare att bolaget kan tidigarelägga förnyelsefönstren för de berörda certifikaten. Eftersom abonnenterna måste fråga förnyelseslutpunkten och agera på de fönster den publicerar kan CA:n styra dem mot ett byte innan en hård återkallelse slår till. Mekanismen beskrivs som en förmåga Cloudflare avser att ha, inte en som bolaget har visat som CA. Ändå håller logiken ihop: kravet på avfrågning finns för att den här spaken ska fungera.

Samma tänkande syns i ett bredare designmål. Cloudflare avser att bygga en certifikatutfärdare vars tillförlitlighet inte bara beror på att undvika misstag, utan, som med resten av Cloudflares produkter, på att fela i det lilla och begränsa följderna av varje enskilt problem. Att undvika misstag är nödvändigt för en CA, och ingen CA kan lova det fullt ut. Att utforma så att ett misstag förblir inringat är den ärligare ingenjörshållningen.

Insyn bortom revisionen #

Offentliga CA bedöms normalt utifrån revisioner. Källan är rak om deras gränser: revisioner är ögonblicksbilder och säger att en CA klarade sig. De säger inte vad CA:n gör en godtycklig tisdag efteråt.

Cloudflares svar är att bolaget säger att det kommer att publicera reproducerbara byggen av den programvara som signerar certifikat. Det framställs som ett åtagande, inte som en färdig leverans. Reproducerbara byggen låter utomstående kontrollera att den binärfil som körs i signeringsvägen motsvarar publicerad källkod, vilket är en löpande egenskap på ett sätt som en revisionsrapport inte är. Om det visar sig räcka beror på vad Cloudflare faktiskt publicerar, och på om andra kontrollerar det.

Tillkännagivandets andra halva: Merkle Tree Certificates #

Postkvantdelen är där tillkännagivandet blickar längst fram. Cloudflare meddelar planer på att bli en av de första CA som erbjuder postkvantcertifikat, och bolaget planerar att utfärda sina första Merkle Tree Certificates under första kvartalet 2027. Ett annat avsnitt i källan säger att de första MTC väntas i början av 2027. Båda är planer.

Källan beskriver MTC som ett nytt och betydligt mer kompakt sätt att leverera offentligt betrodda certifikat. Den formuleringen är en beskrivning, och källan ger inga mätningar i de avsnitt jag arbetar utifrån, så jag kan inte säga hur mycket mer kompakt. Cloudflare säger att bolaget har drivit det standardbaserade förslaget om MTC inom IETF. Det rapporterar också att Chrome tidigare i år utnämnde MTC till den föredragna vägen för postkvantautentisering. Det är en påvisad händelse, och den spelar roll, eftersom en webbläsarleverantörs uttalade preferens är det som gör ett förslag till något en CA kan planera kring.

Cloudflare väntar sig inte att övergången blir plötslig. Bolaget väntar sig att stora delar av internet fortsätter att förlita sig på klassiska certifikat och den befintliga WebPKI i många år till. Under den perioden väntar det sig att MTC tar en stadigt växande andel av utfärdandet. Det är förväntningar, och källan märker dem som sådana.

En CA, en livscykel #

Det arkitekturval som följer av detta är det jag finner mest övertygande. Den nya CA:n är utformad för att bära klassiska certifikat och Merkle Tree Certificates under en CA, med en livscykel och en uppsättning garantier. Kunderna kan då gå över i den takt som passar dem och hjälpa webben att ta steget utan en hård övergång.

Alternativet är två parallella CA, två uppsättningar rutiner och en påtvingad migrering vid någon tidpunkt. En hård övergång är det mest riskfyllda sättet att förändra ett certifikatekosystem, och källans uttalade mål är att undvika en. Formuleringen är försiktig, och med rätta: det här är en designavsikt för en CA som ännu inte utfärdar.

Det passar också incitamentsbilden. Cloudflare säger att bolaget väntar sig att antalet certifikat det förlitar sig på varje år fortsätter att växa i takt med att den högsta giltighetstiden minskar, agentisk aktivitet ökar och postkvantcertifikat blir vardag. Fler certifikat, utfärdade oftare, talar för automatisering och för en CA som behandlar förnyelse som en förstaklassig operation. Ett system byggt kring ARI och en livscykel är ett rimligt svar på den förväntningen, även om förväntningen i sig är en prognos, inte en mätning.

Kund noll #

Hur testar man en CA innan allmänheten förlitar sig på den? Cloudflares svar är att vara sin egen första kund. Bolaget blir kund noll för den nya CA:n och dess certifikat, både WebPKI och MTC. Det uttalade syftet är att säkerställa att alla delar av de nya systemen och processerna håller Cloudflares höga interna standard, och att CA:ns infrastruktur prövas i Cloudflares skala.

Med tanke på de tidigare siffrorna är det en krävande intern last: miljontals certifikat om året, i ett bolag som står framför mer än 20 procent av den globala trafiken av förfrågningar. Om de första driftåren går smidigt är något påståendena inte kan säga oss. Vad de visar är en förnuftig ordningsföljd. Bolaget börjar som storanvändare av det det bygger, med en historia av provisionering via flera CA, reservvägar och 16 partner-CA i ryggen.

Det är värt att vara tydlig med vad som saknas. Ingenting i källan redovisar utfärdandevolymer, felfrekvenser, valideringslatens eller incidenthistorik för Cloudflares egen CA, eftersom det ännu inte finns någon sådan historik. Tillkännagivandet är en avsiktsförklaring som stöds av ansökningar, ett förvärvsavtal och en utformning. Det är inte en meritlista.

Vad man ska hålla ögonen på #

Tre saker avgör om detta blir ett meningsfullt tillskott till WebPKI eller bara ett intressant tillkännagivande.

Den första är rotprogrammen. Cloudflare har ansökt hos Chrome, Apple, Microsoft och Mozilla, och processerna sker öppet. Att följa dem är det mest direkta sättet att se hur långt planen har kommit, och utfallet är inget som något av påståendena låter mig förutsäga.

Den andra är ARI-kravet. En CA som insisterar på stöd för RFC 9773 satsar på att förnyelseautomatisering kan drivas framåt i hela abonnentbasen. Om satsningen är rätt ger den Cloudflare möjlighet att tidigarelägga förnyelsefönster när certifikat måste tas ur bruk, vilket är det uttalade svaret på det återkallelsedilemma bolaget har sett. Om den är fel kommer införandet att gå långsammare än berättelsen om migrering på en rad antyder.

Den tredje är första kvartalet 2027. Det är då Cloudflare planerar sina första Merkle Tree Certificates. Den öppna frågan är hur snabbt den stadigt växande andel bolaget väntar sig faktiskt växer, givet dess egen uppfattning att stora delar av internet stannar kvar på klassiska certifikat i många år till. Bolaget har sagt att steget inte ska kräva en hård övergång. Första kvartalet 2027 blir det första tillfället att se om en CA som bär båda certifikattyperna kan göra det sant.

Vad det innebär per sektor #

Framväxten av en offentlig certifikatutfärdare med hög volym och automatisering hos en leverantör av edge-infrastruktur förändrar den operativa risken och PKI-planeringen inom flera tekniska områden.

Molninfrastruktur och edge-nätverk #

Att driva en offentlig CA i edge-skala minskar det externa beroendet av tredjeparts-API:er för verifiering och av CRL. Genom att koppla ihop TLS-avslutning i omvända proxyer vid kanten med automatiserade ACME ARI-förnyelser kan infrastrukturleverantörer skydda sina kunder mot avbrott hos certifikatutfärdare längre upp i kedjan.

PKI i företag och DevOps-team #

Organisationer som förlitar sig på Let's Encrypt för publika slutpunkter får ett trovärdigt, automatiserat alternativ. Den obligatoriska tillämpningen av RFC 9773 (ARI) innebär dock att teamen måste granska sina ACME-klienter (Certbot, Lego, Caddy, Traefik) för att säkerställa att ARI-stödet är aktivt innan de byter katalogslutpunkt.

Webbläsarleverantörer och styrning av rötter #

Rotprogrammen (Chrome, Mozilla, Apple, Microsoft) möter ett växande ekosystem av automatiserade CA med hög volym. Strategin med två spår för rötter (att förvärva en äldre rot från 2012 och samtidigt skicka in en modern rot) navigerar mellan webbläsarpolicyer som allt mer begränsar rotcertifikatens livslängd och behovet av bakåtkompatibilitet för äldre enheter.

Slutsats #

Cloudflares steg mot att bli en offentlig certifikatutfärdare tar itu med en verklig strukturell sårbarhet i dagens WebPKI: den extrema koncentrationen av gratis, automatiserat certifikatutfärdande. Genom att kombinera en etablerad GlobalSign-rot, strikt förnyelseautomatisering med ARI och en bro framåt till postkvantsäkra Merkle Tree Certificates tar utformningen sikte på operativ motståndskraft snarare än enbart tillhandahållande av certifikat. Framgången avgörs av godkännanden i rotprogrammen och av hur snabbt klientverktygen tar till sig ARI-standarderna inför utrullningen 2027.

Vanliga frågor #

Kan jag byta min ACME-klient till Cloudflares CA i dag?

Inte ännu. Cloudflare har meddelat sin avsikt, tecknat avtalet om förvärv av roten och lämnat in ansökningar till de stora rotprogrammen. Offentligt utfärdande ska rullas ut efter godkännanden i rotprogrammen.

Vad är ACME Renewal Information (ARI) och varför spelar det roll?

ARI (RFC 9773) är en utökning av ACME-protokollet som låter certifikatutfärdare meddela abonnenter när ett certifikat bör förnyas. Det gör att CA kan samordna tidiga förnyelser på ett smidigt sätt inför planerade återkallelser och förhindra avbrott på webbplatser.

Hur skiljer sig Merkle Tree Certificates (MTC) från vanliga X.509-certifikat?

MTC ersätter traditionella enskilda kryptografiska signaturer med bevis på inkludering i ett Merkle-träd, förankrade i en offentligt verifierbar logg. Det minskar certifikatens storlek och överföringskostnad avsevärt, vilket gör dem till en föredragen kandidat för postkvantsäker TLS-autentisering.

Källor #

Cloudflare, (2026). Att bygga en certifikatutfärdare för hela internet ⧉. Cloudflare Blog.
IETF, (2024). RFC 9773: Automated Certificate Management Environment (ACME) Renewal Information (ARI) ⧉. IETF.
IETF, (2025). Merkle Tree Certificates för TLS ⧉. IETF.
Chrome Root Program, (2026). Policy och överväganden kring postkvantautentisering ⧉. Chromium Projects.

Senast granskad 2026-09-20.

Senast granskad 2026-10-27.

Återpublicera den här artikeln

Cloudflares egna certifikat ska motverka koncentrationen av gratis-CA — Sebastien Rousseau

Cloudflare vill bli en offentlig certifikatutfärdare, har ansökt hos Chromes, Apples, Microsofts och Mozillas rotprogram och köper en GlobalSign-rot.

Den här artikeln är licensierad under Creative Commons Attribution 4.0 International. Återpublicering kräver attribution till den kanoniska URL:en.

Cloudflares egna certifikat ska motverka koncentrationen av gratis-CA — Sebastien Rousseau

Cloudflare vill bli en offentlig certifikatutfärdare, har ansökt hos Chromes, Apples, Microsofts och Mozillas rotprogram och köper en GlobalSign-rot.

Originally published at https://sebastienrousseau.com/sv/2026-09-20-cloudflares-egna-certifikat-ska-motverka-koncentrationen/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER