Cloudflare vrea propriile certificate, contra concentrării CA gratuite

Cloudflare s-a bazat ani la rând pe 16 CA publice partenere, fără să emită vreodată el însuși un certificat de încredere publică. Acum intenționează să devină unul, iar partea interesantă este designul: certificate clasice și Merkle Tree Certificates sub aceeași CA, cu limitarea efectelor defecțiunilor gândită de la început.

Un consumator de certificate devine emitent de certificate #

Cele mai multe companii de infrastructură rămân de o singură parte a relației cu certificatele. Solicită certificate, le instalează și se plâng când o CA are un incident. Cloudflare a stat ferm de partea consumatorului. După propria mărturie, nu a emis niciodată el însuși vreun certificat de încredere publică.

Asta urmează să se schimbe, sau cel puțin Cloudflare spune că are această intenție. Compania își anunță intenția de a deveni autoritate de certificare publică. Anunțul este atent la stadiul actual al lucrurilor, și la fel ar trebui să fie acest articol. Cloudflare nu emite încă certificate. Tot ce ține de comportamentul serviciului, de la interfața ACME la regulile de reînnoire și la suportul pentru Merkle Tree Certificates, este o declarație de plan, nu descrierea unui sistem care funcționează.

Ce face anunțul credibil nu este ambiția, ci pregătirea deja vizibilă. Cloudflare a aplicat pentru includerea în programele root Chrome, Apple, Microsoft și Mozilla. Compania spune că parcurge procesul de aplicare și aprobare cu fiecare dintre programele esențiale de chei root ale webului și notează că aceste procese au loc public. Oricine poate, în principiu, urmări dacă aplicația reușește.

De ce este Cloudflare în poziția de a pune întrebarea #

Argumentul Cloudflare pentru construirea unei CA pornește de la poziția sa de client. Se află în fața a peste 20 la sută din traficul global de cereri pe internet. Termină TLS pentru milioane de domenii și se bazează pe milioane de certificate pe an. Oferă clienților pachete de certificate prin Universal SSL și consumă, de asemenea, certificate de la multe CA diferite pentru a-și rula propriile sisteme și operațiunile interne.

Pentru a menține serviciile clienților funcționale, Cloudflare obține aceste certificate prin mai multe CA, cu căi principale și de rezervă, astfel încât serviciile clienților să reziste întreruperilor CA și revocărilor. Rețeaua de CA publice partenere pe care s-a bazat timp de mulți ani numără 16.

Mecanismul de rezervă merită o privire mai atentă, pentru că arată cum gândește Cloudflare defecțiunile. Fiecare certificat Universal SSL vine deja cu un certificat de rezervă, cu o cheie separată și emis de o altă autoritate. Dacă cel principal este vreodată revocat sau compromis, cel de rezervă este gata să fie implementat automat. Este o acoperire împotriva eșecului oricărei CA individuale, construită din partea clientului.

Este însă și o acoperire cu plafon. Poți diversifica doar între CA-urile care există, iar sursa susține că oferta celor capabile este mai subțire decât pare.

Problema concentrării #

Cifrele din spatele acestui argument sunt izbitoare. Let's Encrypt emite în jur de zece milioane de certificate pe zi. Deservește peste 500 de milioane de site-uri și a depășit patru miliarde de certificate active în 2025. Acestea sunt cifrele unei singure CA gratuite și descriu un web a cărui criptare se sprijină puternic pe o singură organizație.

Sursa trage concluzia evidentă, cu o rezervă potrivită: dacă autoritatea de certificare gratuită dominantă ar avea o săptămână proastă, o mare parte a webului nu ar avea o alternativă gratuită și automatizată comparabilă, pregătită să preia sarcina. Este o afirmație despre o ipoteză, iar Cloudflare o prezintă ca atare. Nu pretinde că o astfel de săptămână a avut loc sau că urmează una.

Chiar și așa, logica este ușor de urmărit. O CA gratuită și automatizată este o opțiune de reziliență doar dacă există înainte de urgență. Argumentul Cloudflare este că poate furniza o a doua, la scară. Aș spune că acesta este cel mai puternic motiv comercial și tehnic din anunț și nu depinde de niciuna dintre părțile mai speculative ale planului. Un web care are o singură CA gratuită dominantă și prea puțin altceva este un web cu un singur punct de eșec, oricât de bine ar fi operată acea CA.

Dimensiune	CA tradițională gratuită și automatizată (Let's Encrypt)	CA publică propusă de Cloudflare
Strategia ancorei de încredere	ISRG Root X1 / X2 (root-uri proprii stabilite din 2015 încoace)	Root GlobalSign achiziționat (de încredere din 2012) + root nou
Protocol de emitere	ACME standard (RFC 8555)	ACME cu aplicarea obligatorie a ARI (RFC 9773)
Modelul de revocare	CRL / OCSP + înlocuire de urgență în masă la abonați	Avansarea coordonată a reînnoirilor prin endpointurile ARI
Calea post-cuantică	Semnături X.509 hibride în evaluare	Merkle Tree Certificates (MTC) native, coexistând cu X.509 clasic
Scară și sarcină inițială	~10 mil. certificate/zi pentru peste 500 mil. de site-uri	Validare cu Cloudflare drept client zero, pe peste 20% din traficul web global

Să cumperi un root în loc să aștepți unul #

Cea mai practică decizie din anunț privește root-ul. Cloudflare spune că a semnat un acord definitiv pentru achiziția unui root consacrat, de largă încredere, de la GlobalSign. Sursa dă motivul direct: un root complet nou nu este util pe scară largă timp de ani de zile. Root-ul GlobalSign existent, în schimb, este de încredere în browsere, sisteme de operare și dispozitive din 2012.

Încrederea într-un root vine încet, pentru că root-ul este instalat în dispozitive, iar dispozitivele se actualizează încet. Un root nou poate fi acceptat de toate programele și totuși să nu fie validat pe un telefon mai vechi sau într-un sistem încorporat. Achiziția unui root aflat deja în teren din 2012 ocolește această așteptare, cel puțin în felul în care o prezintă sursa.

Cloudflare nu renunță cu totul la calea unui root nou. Va depune și un root nou pentru includerea în programele de chei root, pe care îl descrie ca fiind construit pentru direcția în care se îndreaptă ecosistemul, inclusiv pentru programele care încep să limiteze cât de vechi poate fi un root de încredere. Acest ultim detaliu amintește util că vârsta taie în ambele sensuri. Vârsta unui root de încredere este un avantaj pentru acoperirea dispozitivelor, iar unele programe se îndreaptă spre limite privind cât de vechi poate fi un root de încredere. Menținerea atât a unui root achiziționat, cât și a unei depuneri noi pare un răspuns la această tensiune, deși sursa nu formulează raționamentul în acești termeni.

Un serviciu ACME întâi, cu condiții #

Adopția este punctul în care multe anunțuri ale CA-urilor devin vagi. Cloudflare este concret. CA-ul său public va fi ACME întâi, adică va vorbi protocolul Automated Certificate Management Environment pe care automatizarea existentă îl folosește deja. Afirmația este că oricine folosește deja o CA gratuită existentă poate trece la CA-ul Cloudflare schimbând un URL de director, fără instrumente noi și fără nimic de rearhitecturat. Este un plan, nu o cale de migrare testată, și ar trebui citit ca atare. Dar o modificare de configurație de o linie este ținta potrivită, pentru că costul migrării este ceea ce îi ține pe oameni la opțiunea implicită.

Capcana este o cerință pe care cei mai mulți utilizatori ACME nu au trebuit să o îndeplinească. Cloudflare va emite doar către clienții care acceptă ACME Renewal Information, sau ARI, standardizat în RFC 9773. Abonații trebuie să mențină o automatizare care interoghează endpointul de reînnoire al Cloudflare, acționează în funcție de ferestrele de reînnoire pe care Cloudflare le publică și identifică certificatul pe care îl înlocuiește.

Este o poziție fermă și cred că este cea corectă. Ridică și o întrebare legitimă despre adopție: o CA care deservește doar clienți compatibili ARI este mai restrânsă decât una care deservește pe oricine are o bibliotecă ACME. Sursa nu spune câți clienți exclude asta astăzi, așa că nu voi ghici. Spune însă de ce vrea Cloudflare această constrângere.

Revocare fără site-uri căzute #

Cloudflare afirmă că a observat anumite lucruri în ultimii 16 ani, iar o observație anume determină acest design. A văzut autorități de certificare prinse între revocarea la timp și menținerea online a site-urilor abonaților.

Această tensiune este reală pentru orice CA. Revocarea rapidă a unui certificat protejează publicul, dar poate scoate din funcțiune orice site care depinde de acel certificat, dacă abonatul nu îl poate înlocui suficient de repede. O CA prinsă la mijloc fie revocă târziu, fie strică site-urile clienților.

ARI este răspunsul Cloudflare. Când certificatele trebuie retrase, Cloudflare spune că poate aduce înainte ferestrele de reînnoire pentru certificatele afectate. Pentru că abonații sunt obligați să interogheze endpointul de reînnoire și să acționeze în funcție de ferestrele publicate, CA-ul îi poate îndruma spre înlocuire înainte să survină o revocare dură. Mecanismul este descris ca o capacitate pe care Cloudflare intenționează să o aibă, nu una pe care a demonstrat-o ca CA. Totuși, logica se susține: cerința de interogare există pentru ca această pârghie să funcționeze.

Aceeași gândire se vede într-un obiectiv de design mai larg. Cloudflare intenționează să construiască o autoritate de certificare a cărei fiabilitate depinde nu doar de evitarea greșelilor, ci, ca în cazul celorlalte produse Cloudflare, de eșecuri mici și de limitarea impactului oricărei probleme individuale. Evitarea greșelilor este necesară pentru o CA, și nicio CA nu o poate promite perfect. Să proiectezi astfel încât o greșeală să rămână izolată este poziția inginerească mai onestă.

Transparență dincolo de audit #

CA-urile publice sunt de regulă judecate după audituri. Sursa este directă în privința limitelor lor: auditurile sunt instantanee și îți spun că o CA a trecut. Nu îți spun ce face CA-ul într-o marți oarecare după aceea.

Răspunsul Cloudflare este să spună că va publica build-uri reproductibile ale software-ului care semnează certificatele. Este prezentat ca un angajament, nu ca un rezultat încheiat. Build-urile reproductibile permit celor din afară să verifice că binarul care rulează pe calea de semnare corespunde sursei publicate, ceea ce este o proprietate continuă într-un fel în care un raport de audit nu este. Dacă asta se dovedește suficient va depinde de ce publică efectiv Cloudflare și de faptul dacă alții verifică.

A doua jumătate a anunțului: Merkle Tree Certificates #

Partea post-cuantică este cea în care anunțul privește cel mai departe. Cloudflare anunță planuri de a fi una dintre primele CA care oferă certificate post-cuantice și plănuiește să emită primele sale Merkle Tree Certificates în primul trimestru din 2027. Un alt pasaj din sursă spune că primele MTC sunt așteptate la începutul lui 2027. Ambele sunt planuri.

Sursa descrie MTC drept o modalitate nouă și mult mai compactă de a livra certificate de încredere publică. Formularea este o descriere, iar sursa nu oferă măsurători în pasajele pe care le folosesc, așa că nu pot spune cu cât mai compactă. Cloudflare spune că a susținut la IETF propunerea bazată pe standarde pentru MTC. Raportează și că Chrome a numit MTC, la începutul acestui an, calea preferată pentru autentificarea post-cuantică. Acesta este un eveniment demonstrat și contează, pentru că preferința declarată a unui producător de browser este ceea ce transformă o propunere în ceva în jurul căruia o CA poate planifica.

Cloudflare nu se așteaptă ca tranziția să fie bruscă. Se așteaptă ca o mare parte a internetului să se bazeze în continuare pe certificate clasice și pe WebPKI-ul existent încă mulți ani. Pe parcursul acestei perioade, se așteaptă ca MTC să ia o cotă tot mai mare din emitere. Acestea sunt așteptări, iar sursa le etichetează ca atare.

O singură CA, un singur ciclu de viață #

Alegerea de arhitectură care decurge de aici este cea pe care o găsesc cea mai convingătoare. Noua CA este proiectată să poarte certificate clasice și Merkle Tree Certificates sub o singură CA, cu un singur ciclu de viață și un singur set de garanții. Clienții pot adopta apoi în ritmul care li se potrivește și pot ajuta webul să facă trecerea fără o comutare bruscă.

Alternativa sunt două CA paralele, două seturi de proceduri și, la un moment dat, o migrare forțată. O comutare bruscă este cel mai riscant mod de a schimba un ecosistem de certificate, iar scopul declarat al sursei este să o evite. Formularea este prudentă, și pe bună dreptate: este o intenție de design pentru o CA care încă nu emite.

Se potrivește și cu tabloul stimulentelor. Cloudflare spune că se așteaptă ca numărul de certificate pe care se bazează anual să continue să crească pe măsură ce perioadele maxime de valabilitate scad, activitatea agentică crește și certificatele post-cuantice devin curente. Mai multe certificate, emise mai des, pledează pentru automatizare și pentru o CA care tratează reînnoirea ca pe o operațiune de prim rang. Un sistem construit în jurul ARI și al unui singur ciclu de viață este un răspuns rezonabil la această așteptare, deși așteptarea însăși este o prognoză, nu o măsurătoare.

Clientul zero #

Cum testezi o CA înainte ca publicul să se bazeze pe ea? Răspunsul Cloudflare este să fie propriul prim client. Va fi clientul zero pentru noua CA și certificatele ei, atât WebPKI, cât și MTC. Scopul declarat este să se asigure că toate aspectele noilor sisteme și procese respectă standardele interne ridicate ale Cloudflare și că infrastructura CA-ului este pusă la încercare la scara Cloudflare.

Având în vedere cifrele de mai devreme, este o sarcină internă solicitantă: milioane de certificate pe an, într-o companie aflată în fața a peste 20 la sută din traficul global de cereri. Dacă primii ani de funcționare vor merge bine este ceva ce afirmațiile nu ne pot spune. Ce arată ele este o ordine rezonabilă a pașilor. Compania pornește ca utilizator intens al lucrului pe care îl construiește, cu un istoric de aprovizionare prin mai multe CA, căi de rezervă și 16 CA partenere în spate.

Merită spus clar ce lipsește. Nimic din sursă nu raportează volume de emitere, rate de eroare, latență de validare sau istoric de incidente pentru propria CA a Cloudflare, pentru că un astfel de istoric nu există încă. Anunțul este o declarație de intenție susținută de aplicații, un acord de achiziție și un design. Nu este un palmares.

Ce trebuie urmărit #

Trei lucruri vor decide dacă aceasta este o completare semnificativă a WebPKI sau doar un anunț interesant.

Primul sunt programele root. Cloudflare a aplicat la Chrome, Apple, Microsoft și Mozilla, iar procesele au loc public. Urmărirea lor este calea cea mai directă de a vedea cât de departe a ajuns planul, iar rezultatul nu este ceva ce vreuna dintre afirmații îmi permite să prezic.

Al doilea este cerința ARI. O CA care insistă pe suportul pentru RFC 9773 pariază că automatizarea reînnoirii poate fi împinsă înainte în întreaga bază de abonați. Dacă pariul este corect, îi dă Cloudflare posibilitatea de a aduce înainte ferestrele de reînnoire când certificatele trebuie retrase, ceea ce este răspunsul declarat la dilema revocării pe care a observat-o. Dacă este greșit, adopția va fi mai lentă decât sugerează povestea migrării dintr-o singură linie.

Al treilea este primul trimestru din 2027. Atunci plănuiește Cloudflare primele sale Merkle Tree Certificates. Întrebarea deschisă este cât de repede va crește efectiv cota tot mai mare la care se așteaptă, dată fiind propria sa părere că o mare parte a internetului va rămâne la certificate clasice încă mulți ani. Compania a spus că trecerea nu ar trebui să necesite o comutare bruscă. Primul trimestru din 2027 va fi prima ocazie de a vedea dacă o singură CA care poartă ambele tipuri de certificate poate face asta adevărat.

Ce înseamnă pe sectoare #

Apariția unei autorități de certificare publice, automatizate și de volum mare, la un furnizor de infrastructură edge schimbă riscul operațional și planificarea PKI în mai multe domenii tehnice.

Infrastructură cloud și rețele edge #

Operarea unei CA publice la scară edge reduce dependența externă de API-urile de verificare și de CRL-urile terților. Prin cuplarea terminării TLS în proxy-urile inverse de la margine cu reînnoiri automate ACME ARI, furnizorii de infrastructură își pot proteja clienții de întreruperile autorităților de certificare din amonte.

PKI în întreprinderi și echipe DevOps #

Organizațiile care se bazează pe Let's Encrypt pentru endpointuri publice câștigă o alternativă credibilă și automatizată. Totuși, aplicarea obligatorie a RFC 9773 (ARI) înseamnă că echipele trebuie să-și auditeze clienții ACME (Certbot, Lego, Caddy, Traefik) pentru a se asigura că suportul ARI este activ înainte de a schimba endpointurile de director.

Producători de browsere și guvernanța root-urilor #

Programele root (Chrome, Mozilla, Apple, Microsoft) se confruntă cu un ecosistem în extindere de CA automatizate de volum mare. Abordarea pe două piste a root-urilor (achiziția unui root vechi din 2012 și depunerea simultană a unui root modern) navighează între politicile browserelor care restricționează tot mai mult durata de viață a certificatelor root și nevoia de compatibilitate cu dispozitivele mai vechi.

Concluzie #

Pasul Cloudflare de a deveni autoritate de certificare publică abordează o vulnerabilitate structurală reală a WebPKI-ului actual: concentrarea extremă a emiterii gratuite și automatizate de certificate. Combinând un root GlobalSign consacrat, o automatizare strictă a reînnoirii prin ARI și o punte spre Merkle Tree Certificates post-cuantice, designul vizează reziliența operațională, nu doar furnizarea de certificate. Succesul va fi determinat de aprobările programelor root și de cât de repede adoptă instrumentele client standardele ARI înaintea lansării din 2027.

Întrebări frecvente #

Îmi pot muta astăzi clientul ACME pe CA-ul Cloudflare?

Încă nu. Cloudflare și-a anunțat intenția, a semnat acordul de achiziție a root-ului și a depus aplicații la principalele programe root. Emiterea publică este programată după aprobările programelor root.

Ce este ACME Renewal Information (ARI) și de ce contează?

ARI (RFC 9773) este o extensie a protocolului ACME care permite autorităților de certificare să le comunice abonaților când ar trebui reînnoit un certificat. Astfel, CA-urile pot coordona fără probleme reînnoiri anticipate înaintea revocărilor planificate, prevenind căderea site-urilor.

Prin ce diferă Merkle Tree Certificates (MTC) de certificatele X.509 standard?

MTC înlocuiesc semnăturile criptografice individuale tradiționale cu dovezi de includere într-un arbore Merkle, ancorate într-un jurnal verificabil public. Asta reduce semnificativ dimensiunea certificatului și costul transmisiei, făcându-le un candidat preferat pentru autentificarea TLS post-cuantică.

Referințe #

Cloudflare, (2026). Construirea unei autorități de certificare pentru întregul internet ⧉. Cloudflare Blog.
IETF, (2024). RFC 9773: Automated Certificate Management Environment (ACME) Renewal Information (ARI) ⧉. IETF.
IETF, (2025). Merkle Tree Certificates pentru TLS ⧉. IETF.
Chrome Root Program, (2026). Politici și considerații privind autentificarea post-cuantică ⧉. Chromium Projects.

Ultima revizuire 2026-09-20.

Ultima revizuire 2026-10-27.

Republică acest articol

Cloudflare vrea propriile certificate, contra concentrării CA gratuite — Sebastien Rousseau

Cloudflare vrea să devină autoritate de certificare publică, a aplicat la programele root Chrome, Apple, Microsoft și Mozilla și cumpără un root GlobalSign.

Acest articol este licențiat sub Creative Commons Attribution 4.0 International. Republicarea necesită atribuirea la URL-ul canonic.

Cloudflare vrea propriile certificate, contra concentrării CA gratuite — Sebastien Rousseau

Cloudflare vrea să devină autoritate de certificare publică, a aplicat la programele root Chrome, Apple, Microsoft și Mozilla și cumpără un root GlobalSign.

Originally published at https://sebastienrousseau.com/ro/2026-09-20-cloudflare-vrea-propriile-certificate-contra-concentrarii/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER