Cloudflare saját tanúsítványai az ingyenes CA-k koncentrációja ellen

A Cloudflare évek óta 16 partner nyilvános CA-ra támaszkodik, és maga még soha nem bocsátott ki nyilvánosan megbízható tanúsítványt. Most azzá akar válni, és a terv érdekes része a kialakítás: klasszikus tanúsítványok és Merkle Tree Certificates egyetlen CA alatt, a hibák hatásának korlátozásával már az elejétől.

A tanúsítványfelhasználóból tanúsítványkibocsátó lesz #

A legtöbb infrastruktúra-vállalat a tanúsítványkapcsolat egyik oldalán marad. Tanúsítványt igényel, telepíti, és panaszkodik, ha egy CA-nál incidens történik. A Cloudflare határozottan a felhasználói oldalon állt. Saját bevallása szerint maga még egyetlen nyilvánosan megbízható tanúsítványt sem bocsátott ki.

Ez hamarosan megváltozik, vagy legalábbis a Cloudflare szerint ez a szándék. A vállalat bejelenti, hogy nyilvános hitelesítésszolgáltatóvá kíván válni. A bejelentés gondosan rögzíti, hol tartanak a dolgok ma, és ennek a cikknek is ezt kell tennie. A Cloudflare még nem bocsát ki tanúsítványokat. A szolgáltatás működésével kapcsolatban minden, az ACME-felülettől a megújítási szabályokon át a Merkle Tree Certificates támogatásáig, terv, nem pedig egy működő rendszer leírása.

A bejelentést nem az ambíció teszi hitelessé, hanem a már látható előkészítés. A Cloudflare kérte felvételét a Chrome, az Apple, a Microsoft és a Mozilla gyökérprogramjába. Azt mondja, hogy a web minden fő gyökérkulcs-programjával végigmegy a jelentkezési és jóváhagyási folyamaton, és megjegyzi, hogy ezek a folyamatok nyilvánosan zajlanak. Elvben bárki követheti, sikerrel jár-e a jelentkezés.

Miért van a Cloudflare abban a helyzetben, hogy feltegye a kérdést #

A Cloudflare érvelése a CA építése mellett ügyfélpozíciójából indul. Az internet globális kérésforgalmának több mint 20 százaléka előtt áll. Több millió domain TLS-kapcsolatát zárja le, és évente több millió tanúsítványra támaszkodik. A Universal SSL révén tanúsítványcsomagokat biztosít ügyfeleinek, és saját rendszerei és belső működése céljára is számos különböző CA tanúsítványait használja.

Az ügyfélszolgáltatások folyamatos működése érdekében a Cloudflare ezeket a tanúsítványokat több CA-n keresztül szerzi be, elsődleges és tartalék útvonalakkal, hogy az ügyfélszolgáltatások a CA-k kieséseit és a visszavonásokat is átvészeljék. A partner nyilvános CA-k hálózata, amelyre sok éve támaszkodik, 16 szolgáltatóból áll.

A tartalékmechanizmus közelebbi vizsgálatot érdemel, mert megmutatja, hogyan gondolkodik a Cloudflare a hibákról. Minden Universal SSL-tanúsítványhoz már most tartozik egy tartaléktanúsítvány, külön kulccsal, egy másik szolgáltató kibocsátásában. Ha az elsődlegest valaha visszavonják vagy kompromittálják, a tartalék automatikusan telepíthető. Ez fedezet bármely egyes CA hibája ellen, a kapcsolat ügyféloldaláról felépítve.

Ennek a fedezetnek azonban van plafonja. Csak a létező CA-k között lehet diverzifikálni, és a forrás szerint az alkalmas szolgáltatók kínálata vékonyabb, mint amilyennek látszik.

A koncentráció problémája #

Az érv mögötti számok megdöbbentőek. A Let's Encrypt nagyságrendileg napi tízmillió tanúsítványt bocsát ki. Több mint 500 millió webhelyet szolgál ki, és 2025-ben átlépte a négymilliárd aktív tanúsítványt. Ezek egyetlen ingyenes CA adatai, és olyan webet írnak le, amelynek titkosítása erősen egyetlen szervezetre támaszkodik.

A forrás levonja a kézenfekvő következtetést, helyénvaló óvatossággal: ha a domináns ingyenes hitelesítésszolgáltatónak rossz hete lenne, a web nagy részének nem lenne hasonló ingyenes, automatizált alternatívája, amely készen állna átvenni a terhelést. Ez egy feltételezett helyzetről szóló állítás, és a Cloudflare így is mutatja be. Nem állítja, hogy ilyen hét már előfordult, vagy hogy közeleg.

Ennek ellenére a logika könnyen követhető. Egy ingyenes, automatizált CA csak akkor ellenálló képességet adó lehetőség, ha a vészhelyzet előtt már létezik. A Cloudflare ajánlata az, hogy nagy léptékben tud biztosítani egy másodikat. Úgy vélem, ez a bejelentés legerősebb üzleti és műszaki érve, és nem függ a terv egyetlen spekulatívabb részétől sem. Egy web, amelynek egy domináns ingyenes CA-ja van és alig más, egyetlen meghibásodási ponttal rendelkező web, bármilyen jó is annak a CA-nak a működése.

Szempont	Hagyományos ingyenes automatizált CA (Let's Encrypt)	A Cloudflare tervezett nyilvános CA-ja
Bizalmi horgony stratégiája	ISRG Root X1 / X2 (saját gyökerek 2015 óta)	Megvásárolt GlobalSign-gyökér (2012 óta megbízható) + új gyökér
Kibocsátási protokoll	Szabványos ACME (RFC 8555)	ACME az ARI (RFC 9773) kötelező érvényesítésével
Visszavonási modell	CRL / OCSP + vészhelyzeti tömeges csere az előfizetőknél	A megújítás összehangolt előrehozása ARI-végpontokon keresztül
Posztkvantum útvonal	Hibrid X.509-aláírások értékelés alatt	Natív Merkle Tree Certificates (MTC) a klasszikus X.509 mellett
Lépték és kezdeti terhelés	~10 millió tanúsítvány/nap több mint 500 millió webhelyen	Validálás a Cloudflare mint nulladik ügyfél révén, a globális webforgalom több mint 20%-án

Gyökeret venni ahelyett, hogy várnánk rá #

A bejelentés leggyakorlatiasabb döntése a gyökérre vonatkozik. A Cloudflare szerint végleges megállapodást írt alá egy bevált, széles körben megbízható gyökér megvásárlásáról a GlobalSigntól. A forrás egyenesen megadja az okot: egy vadonatúj gyökér évekig nem használható széles körben. A meglévő GlobalSign-gyökér ezzel szemben 2012 óta megbízható a böngészőkben, az operációs rendszerekben és az eszközökön.

A gyökér iránti bizalom lassan alakul ki, mert a gyökér az eszközökre települ, az eszközök pedig lassan frissülnek. Egy új gyökeret minden program elfogadhat, és mégsem validálódik egy régebbi telefonon vagy beágyazott rendszerben. Egy 2012 óta használatban lévő gyökér megvásárlása megkerüli ezt a várakozást, legalábbis ahogy a forrás bemutatja.

A Cloudflare nem mond le teljesen az új gyökér útjáról. Új gyökeret is benyújt a gyökérkulcs-programokba, amelyet úgy ír le, hogy azt az irányt szolgálja, amerre az ökoszisztéma tart, beleértve azokat a programokat, amelyek kezdik korlátozni, milyen idős lehet egy megbízható gyökér. Ez az utolsó részlet hasznos emlékeztető arra, hogy a kor kétélű. Egy megbízható gyökér kora előny az eszközlefedettség szempontjából, és egyes programok afelé haladnak, hogy korlátozzák, milyen idős lehet egy megbízható gyökér. Egy megvásárolt gyökér és egy friss benyújtás párhuzamos működtetése válasznak tűnik erre a feszültségre, bár a forrás nem ezekkel a szavakkal fogalmazza meg az érvelést.

ACME-központú szolgáltatás, feltételekkel #

A bevezetésnél válik homályossá sok CA-bejelentés. A Cloudflare konkrét. Nyilvános CA-ja ACME-központú lesz, vagyis az Automated Certificate Management Environment protokollt beszéli, amelyet a meglévő automatizálás már használ. Az állítás az, hogy aki már egy meglévő ingyenes CA-t használ, egy könyvtár-URL módosításával átválthat a Cloudflare CA-jára, új eszközök és átépítés nélkül. Ez terv, nem kipróbált migrációs útvonal, és így is kell olvasni. Az egysoros konfigurációmódosítás azonban a helyes cél, mert a migráció költsége tartja az embereket az alapértelmezett választásnál.

A bökkenő egy olyan követelmény, amelynek a legtöbb ACME-felhasználónak eddig nem kellett megfelelnie. A Cloudflare csak olyan klienseknek bocsát ki tanúsítványt, amelyek támogatják az ACME Renewal Informationt, vagyis az ARI-t, amelyet az RFC 9773 szabványosít. Az előfizetőknek olyan automatizálást kell fenntartaniuk, amely lekérdezi a Cloudflare megújítási végpontját, a Cloudflare által közzétett megújítási ablakok szerint cselekszik, és megjelöli a lecserélt tanúsítványt.

Ez határozott álláspont, és szerintem helyes. Jogos kérdést is felvet a bevezetésről: egy csak ARI-képes klienseket kiszolgáló CA szűkebb, mint az, amely bárkit kiszolgál, akinek ACME-könyvtára van. A forrás nem mondja meg, hány klienst zár ki ez ma, ezért nem fogok találgatni. Azt viszont elmondja, miért akarja a Cloudflare ezt a megkötést.

Visszavonás a webhelyek leállítása nélkül #

A Cloudflare szerint az elmúlt 16 évben sok mindent megfigyelt, és ezt a kialakítást egy megfigyelés vezérli. Látott hitelesítésszolgáltatókat, amelyek az időben történő visszavonás és az előfizetők webhelyeinek elérhetősége közé szorultak.

Ez a feszültség minden CA számára valós. Egy tanúsítvány gyors visszavonása védi a nyilvánosságot, de leállíthat minden webhelyet, amely arra a tanúsítványra támaszkodik, ha az előfizető nem tudja elég gyorsan lecserélni. A kettő közé szorult CA vagy későn von vissza, vagy elrontja az ügyfelei működését.

Az ARI a Cloudflare válasza. Amikor tanúsítványokat kell kivezetni, a Cloudflare szerint előre tudja hozni az érintett tanúsítványok megújítási ablakait. Mivel az előfizetőknek kötelező lekérdezniük a megújítási végpontot és a közzétett ablakok szerint cselekedniük, a CA a kemény visszavonás előtt a csere felé terelheti őket. Ezt a mechanizmust olyan képességként írják le, amellyel a Cloudflare rendelkezni kíván, nem olyanként, amelyet CA-ként már bizonyított. A logika mégis összeáll: a lekérdezési követelmény azért létezik, hogy ez az emelő működjön.

Ugyanez a gondolkodás látszik egy tágabb tervezési célban. A Cloudflare olyan hitelesítésszolgáltatót kíván építeni, amelynek megbízhatósága nemcsak a hibák elkerülésén múlik, hanem, a Cloudflare többi termékéhez hasonlóan, azon, hogy a hibák kicsik maradnak, és minden egyes probléma hatása korlátozott. A hibák elkerülése szükséges egy CA számára, és egyetlen CA sem ígérheti tökéletesen. Úgy tervezni, hogy egy hiba elszigetelt maradjon, az őszintébb mérnöki hozzáállás.

Átláthatóság az auditon túl #

A nyilvános CA-kat általában auditok alapján ítélik meg. A forrás nyíltan beszél korlátaikról: az auditok pillanatfelvételek, és azt mondják meg, hogy egy CA megfelelt. Azt nem, hogy a CA mit csinál utána egy tetszőleges kedden.

A Cloudflare válasza az, hogy közzéteszi a tanúsítványokat aláíró szoftver reprodukálható buildjeit. Ezt vállalásként mutatja be, nem kész eredményként. A reprodukálható buildek lehetővé teszik a kívülállóknak annak ellenőrzését, hogy az aláírási útvonalon futó bináris megfelel a közzétett forráskódnak, ami olyan folyamatos tulajdonság, amilyen egy auditjelentés nem. Hogy ez elegendőnek bizonyul-e, attól függ, mit tesz közzé ténylegesen a Cloudflare, és hogy mások ellenőrzik-e.

A bejelentés második fele: Merkle Tree Certificates #

A posztkvantum rész az, ahol a bejelentés a legmesszebbre tekint. A Cloudflare bejelenti, hogy az elsők között akar posztkvantum tanúsítványokat kínálni, és első Merkle Tree Certificates tanúsítványait 2027 első negyedévében tervezi kibocsátani. A forrás egy másik szakasza szerint az első MTC-k 2027 elején várhatók. Mindkettő terv.

A forrás az MTC-ket a nyilvánosan megbízható tanúsítványok kézbesítésének új és sokkal tömörebb módjaként írja le. Ez a megfogalmazás leírás, és a forrás azokban a szakaszokban, amelyekből dolgozom, nem közöl méréseket, így nem tudom megmondani, mennyivel tömörebb. A Cloudflare szerint az IETF-ben az MTC-kre vonatkozó, szabványokon alapuló javaslat élharcosa. Arról is beszámol, hogy a Chrome az év elején az MTC-ket nevezte meg a posztkvantum hitelesítés előnyben részesített útjaként. Ez bizonyított esemény, és számít, mert egy böngészőgyártó kimondott preferenciája teszi a javaslatot olyasmivé, amire egy CA tervezhet.

A Cloudflare nem számít hirtelen átmenetre. Arra számít, hogy az internet nagy része még sok évig a klasszikus tanúsítványokra és a meglévő WebPKI-ra támaszkodik. Ebben az időszakban arra számít, hogy az MTC-k egyre nagyobb részt vesznek ki a kibocsátásból. Ezek várakozások, és a forrás így is jelöli őket.

Egy CA, egy életciklus #

Az ebből következő architekturális döntést tartom a legmeggyőzőbbnek. Az új CA-t úgy tervezték, hogy a klasszikus tanúsítványokat és a Merkle Tree Certificates-t egyetlen CA alatt hordozza, egy életciklussal és egy garanciakészlettel. Az ügyfelek így a nekik megfelelő tempóban térhetnek át, és segíthetnek a webnek kemény átállás nélkül megtenni a váltást.

Az alternatíva két párhuzamos CA, két eljáráskészlet és valamikor egy kényszerített migráció. A kemény átállás a tanúsítványökoszisztéma megváltoztatásának legkockázatosabb módja, és a forrás kimondott célja ennek elkerülése. A megfogalmazás óvatos, és joggal: ez egy még nem kibocsátó CA tervezési szándéka.

Ez illeszkedik az ösztönzők képéhez is. A Cloudflare szerint arra számít, hogy az évente használt tanúsítványainak száma tovább nő, ahogy a maximális érvényességi idők csökkennek, az ágensalapú tevékenység nő, és a posztkvantum tanúsítványok általánossá válnak. Több tanúsítvány, gyakrabban kibocsátva, az automatizálás mellett szól, és egy olyan CA mellett, amely a megújítást elsőrendű műveletként kezeli. Az ARI-ra és egyetlen életciklusra épülő rendszer észszerű válasz erre a várakozásra, bár maga a várakozás előrejelzés, nem mérés.

A nulladik ügyfél #

Hogyan teszteljünk egy CA-t, mielőtt a nyilvánosság támaszkodna rá? A Cloudflare válasza az, hogy saját első ügyfele lesz. Az új CA és tanúsítványai, a WebPKI és az MTC esetében is ő lesz a nulladik ügyfél. A kimondott cél annak biztosítása, hogy az új rendszerek és folyamatok minden eleme megfeleljen a Cloudflare magas belső követelményeinek, és hogy a CA infrastruktúráját Cloudflare-léptékben vegyék igénybe.

A korábbi számok fényében ez megterhelő belső terhelés: évente több millió tanúsítvány egy olyan vállalatnál, amely a globális kérésforgalom több mint 20 százaléka előtt áll. Hogy az első működési évek simán telnek-e, azt az állítások nem árulják el. Azt viszont megmutatják, hogy a lépések sorrendje észszerű. A vállalat annak nagy felhasználójaként indul, amit épít, a több CA-n keresztüli beszerzés, a tartalék útvonalak és a mögötte álló 16 partner CA tapasztalatával.

Érdemes világosan kimondani, mi hiányzik. A forrásban semmi sem közöl kibocsátási volument, hibaarányt, validálási késleltetést vagy incidenstörténetet a Cloudflare saját CA-járól, mert ilyen előzmény még nincs. A bejelentés szándéknyilatkozat, amelyet jelentkezések, egy vásárlási megállapodás és egy kialakítás támaszt alá. Nem eredménylista.

Mire érdemes figyelni #

Három dolog dönti el, hogy ez érdemi hozzájárulás lesz-e a WebPKI-hoz, vagy csupán egy érdekes bejelentés.

Az első a gyökérprogramok. A Cloudflare a Chrome-hoz, az Apple-höz, a Microsofthoz és a Mozillához jelentkezett, és a folyamatok nyilvánosan zajlanak. Ezek követése a legközvetlenebb módja annak, hogy lássuk, hol tart a terv, és az eredményt egyik állítás sem teszi számomra előre jelezhetővé.

A második az ARI-követelmény. Egy CA, amely ragaszkodik az RFC 9773 támogatásához, arra fogad, hogy a megújítás automatizálása az előfizetői bázis egészén előremozdítható. Ha a fogadás bejön, a Cloudflare előre hozhatja a megújítási ablakokat, amikor tanúsítványokat kell kivezetni, ami a kimondott válasz az általa látott visszavonási dilemmára. Ha nem, a bevezetés lassabb lesz, mint amit az egysoros migráció története sugall.

A harmadik 2027 első negyedéve. A Cloudflare ekkorra tervezi első Merkle Tree Certificates tanúsítványait. A nyitott kérdés az, milyen gyorsan nő ténylegesen az általa várt, egyre nagyobb részarány, tekintve saját nézetét, hogy az internet nagy része még sok évig a klasszikus tanúsítványoknál marad. A vállalat azt mondta, hogy a váltáshoz nem kellene kemény átállás. 2027 első negyedéve lesz az első alkalom annak megítélésére, hogy egy mindkét tanúsítványtípust hordozó CA ezt valóra tudja-e váltani.

Mit jelent ez ágazatonként #

Egy nagy volumenű, automatizált nyilvános hitelesítésszolgáltató megjelenése egy peremhálózati infrastruktúra-szolgáltatónál több műszaki területen is megváltoztatja a működési kockázatot és a PKI-tervezést.

Felhőinfrastruktúra és peremhálózatok #

Egy nyilvános CA peremhálózati léptékű működtetése csökkenti a harmadik felek ellenőrző API-jaitól és CRL-jeitől való külső függést. A peremen működő fordított proxyk TLS-lezárásának és az automatizált ACME ARI-megújításoknak az összekapcsolásával az infrastruktúra-szolgáltatók megvédhetik ügyfeleiket a láncban feljebb lévő hitelesítésszolgáltatók kieséseitől.

Vállalati PKI és DevOps-csapatok #

A nyilvános végpontjaikhoz a Let's Encryptre támaszkodó szervezetek hiteles, automatizált alternatívát kapnak. Az RFC 9773 (ARI) kötelező érvényesítése azonban azt jelenti, hogy a csapatoknak át kell vizsgálniuk ACME-klienseiket (Certbot, Lego, Caddy, Traefik), és meg kell győződniük az ARI-támogatás aktív voltáról, mielőtt könyvtárvégpontot váltanak.

Böngészőgyártók és a gyökerek irányítása #

A gyökérprogramok (Chrome, Mozilla, Apple, Microsoft) a nagy volumenű automatizált CA-k bővülő ökoszisztémájával szembesülnek. A kétpályás gyökérstratégia (egy 2012-es régi gyökér megvásárlása és ezzel egy időben egy modern gyökér benyújtása) azok között a böngészőirányelvek között navigál, amelyek egyre inkább korlátozzák a gyökértanúsítványok élettartamát, miközben megőrzi a visszafelé kompatibilitást a régebbi eszközökkel.

Összegzés #

A Cloudflare lépése, hogy nyilvános hitelesítésszolgáltatóvá váljon, a mai WebPKI valódi szerkezeti sebezhetőségét kezeli: az ingyenes, automatizált tanúsítványkibocsátás szélsőséges koncentrációját. Egy bevált GlobalSign-gyökér, a szigorú ARI-alapú megújítási automatizálás és a posztkvantum Merkle Tree Certificates felé vezető híd ötvözésével a kialakítás a működési ellenálló képességet célozza, nem csupán a tanúsítványok biztosítását. A sikert a gyökérprogramok jóváhagyásai és az döntik el, milyen gyorsan veszik át a klienseszközök az ARI-szabványokat a 2027-es bevezetés előtt.

Gyakran ismételt kérdések #

Átállíthatom már ma az ACME-kliensemet a Cloudflare CA-jára?

Még nem. A Cloudflare bejelentette szándékát, aláírta a gyökér megvásárlásáról szóló megállapodást, és benyújtotta jelentkezéseit a fő gyökérprogramokba. A nyilvános kibocsátás a gyökérprogramok jóváhagyásai után indul.

Mi az ACME Renewal Information (ARI), és miért fontos?

Az ARI (RFC 9773) az ACME protokoll olyan kiterjesztése, amellyel a hitelesítésszolgáltatók jelezhetik az előfizetőknek, mikor kell egy tanúsítványt megújítani. Így a CA-k zökkenőmentesen összehangolhatják a korai megújításokat a tervezett visszavonások előtt, megelőzve a webhelyek kiesését.

Miben különböznek a Merkle Tree Certificates (MTC) a szabványos X.509-tanúsítványoktól?

Az MTC-k a hagyományos egyedi kriptográfiai aláírásokat Merkle-fába való tartozást igazoló bizonyítékokkal váltják fel, amelyek egy nyilvánosan ellenőrizhető naplóhoz vannak horgonyozva. Ez jelentősen csökkenti a tanúsítvány méretét és az átviteli többletterhelést, így előnyben részesített jelöltté teszi őket a posztkvantum TLS-hitelesítéshez.

Hivatkozások #

Cloudflare, (2026). Hitelesítésszolgáltató építése az egész internet számára ⧉. Cloudflare Blog.
IETF, (2024). RFC 9773: Automated Certificate Management Environment (ACME) Renewal Information (ARI) ⧉. IETF.
IETF, (2025). Merkle Tree Certificates a TLS-hez ⧉. IETF.
Chrome Root Program, (2026). Irányelvek és szempontok a posztkvantum hitelesítéshez ⧉. Chromium Projects.

Utolsó felülvizsgálat 2026-09-20.

Utolsó felülvizsgálat 2026-10-27.

A cikk újraközlése

Cloudflare saját tanúsítványai az ingyenes CA-k koncentrációja ellen — Sebastien Rousseau

A Cloudflare nyilvános hitelesítésszolgáltató akar lenni: jelentkezett a Chrome, az Apple, a Microsoft és a Mozilla gyökérprogramjába, és GlobalSign-gyökeret vesz.

Ez a cikk a következő licenc alatt áll: Creative Commons Attribution 4.0 International. Az újraközléshez a kanonikus URL forrásmegjelölése szükséges.

Cloudflare saját tanúsítványai az ingyenes CA-k koncentrációja ellen — Sebastien Rousseau

A Cloudflare nyilvános hitelesítésszolgáltató akar lenni: jelentkezett a Chrome, az Apple, a Microsoft és a Mozilla gyökérprogramjába, és GlobalSign-gyökeret vesz.

Originally published at https://sebastienrousseau.com/hu/2026-09-20-cloudflare-sajat-tanusitvanyai-ingyenes-ca-koncentracioja/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER