Cloudflare vuole diventare CA contro la concentrazione di CA gratuite

Cloudflare si affida da anni a 16 CA pubbliche partner senza aver mai emesso in proprio un certificato di fiducia pubblica. Ora intende diventarne una, e la parte interessante è il progetto: certificati classici e Merkle Tree Certificates sotto un'unica CA, con il contenimento dei guasti previsto fin dall'inizio.

Un consumatore di certificati diventa emittente #

La maggior parte delle aziende di infrastruttura resta su un solo lato del rapporto con i certificati. Li richiedono, li installano e si lamentano quando una CA ha un incidente. Cloudflare è stata saldamente dal lato del consumo. Per sua stessa ammissione, non ha mai emesso in proprio un solo certificato di fiducia pubblica.

La situazione sta per cambiare, o almeno Cloudflare dice di volerlo. L'azienda annuncia l'intenzione di diventare un'autorità di certificazione pubblica. L'annuncio è prudente su dove stiano oggi le cose, e lo deve essere anche questo articolo. Cloudflare non emette ancora certificati. Tutto ciò che riguarda il comportamento del servizio, dall'interfaccia ACME alle regole di rinnovo fino al supporto dei Merkle Tree Certificates, è una dichiarazione di intenti e non la descrizione di un sistema in funzione.

A rendere credibile l'annuncio non è l'ambizione ma il lavoro preparatorio già visibile. Cloudflare ha chiesto l'inclusione nei programmi root di Chrome, Apple, Microsoft e Mozilla. Dice di stare seguendo il processo di candidatura e approvazione con ciascuno dei principali programmi di chiavi root del web, e osserva che questi processi si svolgono in pubblico. Chiunque può, in linea di principio, verificare se la candidatura andrà a buon fine.

Perché Cloudflare è nella posizione di porre la domanda #

L'argomento di Cloudflare a favore di una propria CA parte dalla sua posizione di cliente. Si trova davanti a oltre il 20 per cento del traffico mondiale di richieste Internet. Termina il TLS per milioni di domini e dipende da milioni di certificati all'anno. Fornisce pacchetti di certificati ai propri clienti tramite Universal SSL, e consuma anche certificati di molte CA diverse per far funzionare i propri sistemi e le operazioni interne.

Per mantenere attivi i servizi dei clienti, Cloudflare ottiene quei certificati tramite più CA, con percorsi primari e di riserva, così che i servizi restino attivi durante i guasti di una CA e gli eventi di revoca. La rete di CA pubbliche partner su cui si appoggia da molti anni ne conta 16.

Il meccanismo di riserva merita un'occhiata più attenta, perché mostra come Cloudflare ragiona sui guasti. Ogni certificato Universal SSL viene già fornito con un certificato di riserva, protetto da una chiave separata ed emesso da un'altra autorità. Se il primario viene revocato o compromesso, quello di riserva è pronto per essere distribuito automaticamente. È una copertura contro il cedimento di una singola CA, costruita dal lato cliente del rapporto.

È però anche una copertura con un tetto. Si può diversificare solo tra le CA che esistono, e la fonte sostiene che l'offerta di CA capaci sia più scarsa di quanto sembri.

Il problema della concentrazione #

I numeri dietro questo ragionamento colpiscono. Let's Encrypt emette nell'ordine di dieci milioni di certificati al giorno. Serve oltre 500 milioni di siti e nel 2025 ha superato i quattro miliardi di certificati attivi. Sono i dati di una sola CA gratuita, e descrivono un web la cui cifratura poggia in larga misura su un'unica organizzazione.

La fonte trae la conclusione ovvia, con una cautela appropriata: se l'autorità di certificazione gratuita dominante vivesse una brutta settimana, gran parte del web non avrebbe un'alternativa gratuita e automatizzata paragonabile pronta a farsi carico del lavoro. È un'affermazione su un'ipotesi, e Cloudflare la presenta come tale. Non sostiene che una settimana del genere sia avvenuta né che stia per arrivare.

La logica resta comunque facile da seguire. Una CA gratuita e automatizzata è un'opzione di resilienza solo se esiste prima dell'emergenza. La proposta di Cloudflare è di poterne offrire una seconda su larga scala. Direi che è la ragione commerciale e tecnica più solida dell'annuncio, e non dipende da nessuna delle parti più speculative del piano. Un web che ha una sola CA gratuita dominante e poco altro è un web con un singolo punto di guasto, qualunque sia la qualità delle operazioni di quella CA.

Dimensione	CA gratuita e automatizzata tradizionale (Let's Encrypt)	CA pubblica proposta da Cloudflare
Strategia di ancora di fiducia	ISRG Root X1 / X2 (root interne create dal 2015)	Root GlobalSign acquisita (affidabile dal 2012) + nuova root
Protocollo di emissione	ACME standard (RFC 8555)	ACME con applicazione obbligatoria di ARI (RFC 9773)
Paradigma di revoca	CRL / OCSP + sostituzione massiva d'emergenza presso gli abbonati	Anticipo coordinato del rinnovo tramite endpoint ARI
Percorso post-quantistico	Firme X.509 ibride in valutazione	Merkle Tree Certificates (MTC) nativi in coesistenza con X.509 classico
Scala e carico iniziale	~10 mln di certificati al giorno su oltre 500 mln di siti	Validazione Customer Zero su oltre il 20 % del traffico web mondiale

Comprare una root invece di aspettarla #

La decisione più pratica dell'annuncio riguarda la root. Cloudflare afferma di aver firmato un accordo definitivo per acquisire da GlobalSign una root consolidata e ampiamente affidabile. La fonte ne dà il motivo in modo diretto: una root nuova di zecca non è davvero utile per anni. La root GlobalSign esistente, invece, è considerata affidabile da browser, sistemi operativi e dispositivi dal 2012.

La fiducia in una root cresce lentamente perché è installata nei dispositivi, e i dispositivi si aggiornano lentamente. Una nuova root può essere accettata da tutti i programmi e non essere comunque validata su un telefono vecchio o su un sistema embedded. Acquisire una root già sul campo dal 2012 evita quell'attesa, almeno nel modo in cui la fonte la presenta.

Cloudflare non abbandona del tutto la strada di una nuova root. Presenterà anche una nuova root per l'inclusione nei programmi di chiavi root, che descrive come pensata per la direzione in cui va l'ecosistema, compresi programmi che cominciano a porre un limite all'età di una root affidabile. Quest'ultimo dettaglio ricorda utilmente che l'età taglia in entrambe le direzioni. L'anzianità di una root affidabile è un vantaggio per la copertura dei dispositivi, e alcuni programmi si stanno muovendo verso limiti sull'età delle root affidabili. Gestire sia una root acquisita sia una nuova candidatura sembra una risposta a questa tensione, anche se la fonte non esplicita il ragionamento in questi termini.

Un servizio ACME-first con delle condizioni #

L'adozione è il punto in cui molti annunci di CA diventano vaghi. Cloudflare è precisa. La sua CA pubblica sarà ACME-first, cioè parlerà il protocollo Automated Certificate Management Environment già usato dall'automazione esistente. L'affermazione è che chiunque punti già a una CA gratuita esistente può passare alla CA di Cloudflare cambiando un URL di directory, senza nuovi strumenti e senza riprogettare nulla. È un piano, non un percorso di migrazione collaudato, e va letto come tale. Ma una modifica di configurazione di una riga è l'obiettivo giusto, perché è il costo della migrazione a tenere le persone su un'impostazione predefinita.

Il rovescio è un requisito che la maggior parte degli utenti ACME non ha mai dovuto soddisfare. Cloudflare emetterà solo verso client che supportano ACME Renewal Information, o ARI, standardizzato nella RFC 9773. Gli abbonati devono mantenere un'automazione che interroghi l'endpoint di rinnovo di Cloudflare, agisca secondo le finestre di rinnovo che Cloudflare pubblica e identifichi il certificato che sta sostituendo.

È una posizione netta, e credo sia quella giusta. Solleva però una domanda legittima sull'adozione: una CA che serve solo client compatibili con ARI è più ristretta di una che serve chiunque abbia una libreria ACME. La fonte non dice quanti client escluda oggi, quindi non tirerò a indovinare. Quello che dice è perché Cloudflare voglia questo vincolo.

Revocare senza far cadere i siti #

Cloudflare afferma di aver osservato alcune cose negli ultimi 16 anni, e una di queste osservazioni guida il progetto. Ha visto autorità di certificazione strette tra una revoca tempestiva e il mantenimento online dei siti dei propri abbonati.

Questa tensione è reale per qualsiasi CA. Revocare rapidamente un certificato protegge il pubblico, ma può far cadere ogni sito che dipende da quel certificato se l'abbonato non riesce a sostituirlo abbastanza in fretta. Una CA presa nel mezzo o revoca tardi o fa cadere i clienti.

ARI è la risposta di Cloudflare. Quando i certificati devono essere ritirati, Cloudflare dice di poter anticipare le finestre di rinnovo dei certificati interessati. Poiché gli abbonati sono tenuti a interrogare l'endpoint di rinnovo e ad agire secondo le finestre pubblicate, la CA può guidarli verso la sostituzione prima che arrivi una revoca netta. Questo meccanismo è descritto come una capacità che Cloudflare intende avere, non come una che abbia dimostrato in qualità di CA. La logica regge comunque: l'obbligo di interrogazione esiste perché questa leva funzioni.

Lo stesso ragionamento emerge in un obiettivo di progetto più ampio. Cloudflare intende costruire un'autorità di certificazione la cui affidabilità non dipenda solo dall'evitare errori ma, come per il resto dei prodotti Cloudflare, dal fallire in piccolo e limitare l'impatto di ogni singolo problema. Evitare gli errori è necessario per una CA, e nessuna CA può prometterlo alla perfezione. Progettare in modo che un errore resti contenuto è la posizione ingegneristica più onesta.

Trasparenza oltre l'audit #

Le CA pubbliche vengono di norma giudicate in base agli audit. La fonte è schietta sui loro limiti: gli audit sono istantanee e ti dicono che una CA li ha superati. Non ti dicono cosa fa la CA in un martedì qualsiasi successivo.

La risposta di Cloudflare è dichiarare che pubblicherà build riproducibili del software che firma i certificati. È presentato come un impegno, non come un risultato già consegnato. Le build riproducibili consentono a terzi di verificare che il binario in esecuzione nel percorso di firma corrisponda al codice sorgente pubblicato, il che è una proprietà continua, cosa che un rapporto di audit non è. Se basterà dipenderà da ciò che Cloudflare pubblicherà davvero e dal fatto che altri lo verifichino.

La seconda metà dell'annuncio: i Merkle Tree Certificates #

La parte post-quantistica è quella in cui l'annuncio guarda più lontano. Cloudflare annuncia di voler essere una delle prime CA a servire certificati post-quantistici, e prevede di emettere i primi Merkle Tree Certificates nel primo trimestre del 2027. Un altro passaggio della fonte dice che i primi MTC sono attesi all'inizio del 2027. Entrambi sono piani.

La fonte descrive gli MTC come un modo nuovo e molto più compatto di consegnare certificati di fiducia pubblica. Questa formulazione è una descrizione, e la fonte non fornisce misure nei passaggi su cui mi baso, quindi non posso dire quanto siano più compatti. Cloudflare dice di aver sostenuto all'IETF la proposta basata su standard per gli MTC. Riferisce inoltre che all'inizio di quest'anno Chrome ha indicato gli MTC come percorso preferito per l'autenticazione post-quantistica. Questo è un fatto dimostrato, e conta, perché la preferenza dichiarata di un produttore di browser è ciò che trasforma una proposta in qualcosa su cui una CA può pianificare.

Cloudflare non si aspetta una transizione improvvisa. Prevede che gran parte di Internet continuerà a basarsi sui certificati classici e sulla WebPKI esistente ancora per molti anni. In quell'arco di tempo, si aspetta che gli MTC conquistino una quota di emissione in crescita costante. Sono aspettative, e la fonte le presenta come tali.

Una CA, un ciclo di vita #

La scelta architetturale che ne deriva è quella che trovo più convincente. La nuova CA è progettata per gestire certificati classici e Merkle Tree Certificates sotto un'unica CA, con un solo ciclo di vita e un solo insieme di garanzie. I clienti possono così adottarla al ritmo che preferiscono e aiutare il web a compiere il passaggio senza una cesura netta.

L'alternativa sarebbe due CA parallele, due insiemi di procedure e una migrazione forzata a un certo punto. Una cesura netta è il modo più rischioso di cambiare un ecosistema di certificati, e l'obiettivo dichiarato della fonte è evitarla. La formulazione è prudente, e a ragione: si tratta di un'intenzione progettuale per una CA che non emette ancora.

Si accorda anche con il quadro degli incentivi. Cloudflare dice di aspettarsi che il numero di certificati da cui dipende ogni anno continui a crescere man mano che i periodi massimi di validità si riducono, l'attività agentica aumenta e i certificati post-quantistici si diffondono. Più certificati, emessi più spesso, depongono a favore dell'automazione e di una CA che tratti il rinnovo come un'operazione di primo piano. Un sistema costruito attorno ad ARI e a un unico ciclo di vita è una risposta ragionevole a questa aspettativa, anche se l'aspettativa stessa è una previsione e non una misura.

Customer Zero #

Come si collauda una CA prima che il pubblico vi faccia affidamento? La risposta di Cloudflare è essere il proprio primo cliente. Sarà il Customer Zero della nuova CA e dei suoi certificati, sia WebPKI sia MTC. Lo scopo dichiarato è garantire che tutti gli aspetti dei nuovi sistemi e processi rispettino gli elevati standard interni di Cloudflare, e che l'infrastruttura della CA venga messa alla prova alla scala di Cloudflare.

Considerati i numeri precedenti, è un carico interno impegnativo: milioni di certificati all'anno, in un'azienda che si trova davanti a oltre il 20 per cento del traffico mondiale di richieste. Le affermazioni non possono dirci se i primi anni di esercizio andranno lisci. Mostrano però un ordine delle operazioni sensato. L'azienda parte come utente intensivo di ciò che sta costruendo, con una storia di approvvigionamento da più CA, percorsi di riserva e 16 CA partner alle spalle.

Vale la pena dire chiaramente cosa manca. Nulla nella fonte riporta volumi di emissione, tassi di errore, latenza di validazione o storico degli incidenti per la CA di Cloudflare, perché uno storico del genere non esiste ancora. L'annuncio è una dichiarazione d'intenti sostenuta da candidature, un accordo di acquisizione e un progetto. Non è un curriculum.

Cosa osservare #

Tre elementi decideranno se si tratta di un'aggiunta significativa alla WebPKI o semplicemente di un annuncio interessante.

Il primo sono i programmi root. Cloudflare ha presentato domanda a Chrome, Apple, Microsoft e Mozilla, e i processi sono pubblici. Seguirli è il modo più diretto per vedere fin dove è arrivato il piano, e nessuna delle affermazioni mi consente di prevederne l'esito.

Il secondo è il requisito ARI. Una CA che pretende il supporto della RFC 9773 scommette che l'automazione del rinnovo possa essere spinta in avanti in tutta la sua base di abbonati. Se la scommessa è giusta, dà a Cloudflare la possibilità di anticipare le finestre di rinnovo quando i certificati devono essere ritirati, che è la risposta dichiarata al dilemma della revoca che ha osservato. Se è sbagliata, l'adozione sarà più lenta di quanto lasci intendere il racconto della migrazione in una riga.

Il terzo è il primo trimestre del 2027. È allora che Cloudflare prevede i suoi primi Merkle Tree Certificates. La questione aperta è con quale rapidità crescerà davvero la quota in crescita costante che si aspetta, data la sua stessa convinzione che gran parte di Internet resterà sui certificati classici ancora per molti anni. L'azienda ha detto che il passaggio non dovrebbe richiedere una cesura netta. Il primo trimestre del 2027 sarà la prima occasione per vedere se una CA che gestisce entrambi i tipi di certificato può renderlo vero.

Cosa significa per settore #

L'arrivo di un'autorità di certificazione pubblica automatizzata e ad alto volume da parte di un fornitore di infrastruttura edge modifica il rischio operativo e la pianificazione PKI in diversi ambiti tecnici.

Infrastruttura cloud e reti edge #

Gestire una CA pubblica su scala edge riduce la dipendenza esterna dalle API di verifica e dalle CRL di terzi. Abbinando la terminazione edge tramite reverse proxy ai rinnovi automatizzati ACME ARI, i fornitori di infrastruttura possono proteggere i propri clienti dai guasti delle autorità di certificazione a monte.

PKI aziendale e team DevOps #

Le organizzazioni che si affidano a Let's Encrypt per gli endpoint pubblici ottengono un'alternativa automatizzata credibile. Tuttavia, l'applicazione obbligatoria della RFC 9773 (ARI) significa che i team devono verificare i propri client ACME (Certbot, Lego, Caddy, Traefik) per assicurarsi che il supporto ARI sia attivo prima di cambiare endpoint di directory.

Produttori di browser e governance delle root #

I programmi root (Chrome, Mozilla, Apple, Microsoft) si trovano di fronte a un ecosistema in espansione di CA automatizzate ad alto volume. L'approccio a doppio binario sulle root (acquisire una root storica del 2012 presentandone al contempo una moderna) si muove tra politiche dei browser che limitano sempre più la durata dei certificati root e la compatibilità con i dispositivi più vecchi.

Conclusione #

La scelta di Cloudflare di diventare un'autorità di certificazione pubblica affronta una reale vulnerabilità strutturale della WebPKI moderna: l'estrema concentrazione nell'emissione gratuita e automatizzata di certificati. Combinando una root GlobalSign consolidata, una rigorosa automazione del rinnovo con ARI e un ponte verso i Merkle Tree Certificates post-quantistici, il progetto punta alla resilienza operativa più che al semplice approvvigionamento di certificati. Il successo dipenderà dalle approvazioni dei programmi root e dalla rapidità con cui gli strumenti client adotteranno gli standard ARI prima del lancio del 2027.

Domande frequenti #

Posso già oggi passare il mio client ACME alla CA di Cloudflare?

Non ancora. Cloudflare ha annunciato le proprie intenzioni, firmato l'accordo di acquisizione della root e presentato domanda ai principali programmi root. L'emissione pubblica è prevista dopo le approvazioni dei programmi root.

Che cos'è ACME Renewal Information (ARI) e perché è importante?

ARI (RFC 9773) è un'estensione del protocollo ACME che consente alle autorità di certificazione di indicare agli abbonati quando un certificato va rinnovato. In questo modo le CA possono coordinare senza scosse rinnovi anticipati prima di revoche pianificate, evitando interruzioni dei siti.

In che cosa i Merkle Tree Certificates (MTC) differiscono dai certificati X.509 standard?

Gli MTC sostituiscono le tradizionali firme crittografiche individuali con prove di inclusione Merkle ancorate a un registro verificabile pubblicamente. Questo riduce in modo significativo le dimensioni dei certificati e il sovraccarico di trasmissione, rendendoli un candidato privilegiato per l'autenticazione TLS post-quantistica.

Riferimenti #

Cloudflare, (2026). Costruire un'autorità di certificazione per l'intera Internet ⧉. Blog di Cloudflare.
IETF, (2024). RFC 9773: Automated Certificate Management Environment (ACME) Renewal Information (ARI) ⧉. IETF.
IETF, (2025). Merkle Tree Certificates per TLS ⧉. IETF.
Chrome Root Program, (2026). Politica e considerazioni sull'autenticazione post-quantistica ⧉. Chromium Projects.

Ultima revisione 2026-09-20.

Ultima revisione 2026-10-27.

Ripubblica questo articolo

Cloudflare vuole diventare CA contro la concentrazione di CA gratuite — Sebastien Rousseau

Cloudflare vuole diventare un'autorità di certificazione pubblica: candidatura ai programmi root, acquisto di una root GlobalSign, ARI obbligatorio e certificati Merkle.

Questo articolo è pubblicato con licenza Creative Commons Attribution 4.0 International. La ripubblicazione richiede l'attribuzione all'URL canonico.

Cloudflare vuole diventare CA contro la concentrazione di CA gratuite — Sebastien Rousseau

Cloudflare vuole diventare un'autorità di certificazione pubblica: candidatura ai programmi root, acquisto di una root GlobalSign, ARI obbligatorio e certificati Merkle.

Originally published at https://sebastienrousseau.com/it/2026-09-20-cloudflare-vuole-diventare-ca-contro-concentrazione/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER