Cloudflare diventa una Certificate Authority: cosa cambia per HTTPS

Cloudflare vuole diventare un’Autorità di certificazione (CA, Certificate Authority) pubblica e iniziare a emettere direttamente i certificati TLS che permettono a browser e server di stabilire connessioni HTTPS considerate affidabili. La società gestisce già una quota enorme del traffico web mondiale, termina connessioni TLS per milioni di domini e, fino a oggi, ha sempre fatto affidamento su autorità di certificazione esterne.

Il 29 settembre 2026 Cloudflare ha annunciato di aver presentato domanda per entrare nei programmi root di Chrome, Apple, Microsoft e Mozilla, affiancando a questa procedura un accordo per acquisire da GlobalSign una root CA già presente da anni negli archivi di certificati attendibili di browser, sistemi operativi e molti dispositivi. In pratica, invece di attendere che una nuova root Cloudflare si diffonda gradualmente attraverso gli aggiornamenti software, l’azienda potrà contare anche su una radice di fiducia già riconosciuta da una vasta base installata.

Let’s Encrypt, lanciata pubblicamente nel 2015, nel 2026 protegge oltre 700 milioni di siti e già alla fine del 2025 arrivava a emettere circa 10 milioni di certificati in alcune giornate. Ora Cloudflare vuole intervenire direttamente sul livello sottostante: non più soltanto usare le CA, ma diventare essa stessa una delle entità alle quali browser e sistemi operativi affidano la costruzione della catena di fiducia.

Cloudflare vuole offrire certificati gratuiti e automatizzati

Cloudflare non sta ancora emettendo certificati trusted: l’annuncio riguarda la costruzione della nuova CA, l’ingresso nei root program e l’infrastruttura che dovrà sostenerla. Il progetto comprende inoltre una componente decisamente più ambiziosa: preparare l’autenticazione HTTPS alla crittografia post-quantum usando i Merkle Tree Certificates, con una prima emissione prevista da Cloudflare per il primo trimestre del 2027.

Come già anticipato nell’introduzione, con Cloudflare che scende in campo in prima linea, il riferimento inevitabile è Let’s Encrypt. Cloudflare riconosce apertamente il ruolo decisivo svolto dalla CA gestita da Internet Security Research Group e non presenta la nuova iniziativa come un tentativo di sostituirla. L’obiettivo dichiarato è aumentare la diversificazione dell’offerta gratuita di certificati digitali.

Cloudflare dichiara che la CA nascerà come servizio ACME-first. ACME, Automated Certificate Management Environment, è il protocollo standardizzato dall’IETF con RFC 8555 e reso popolare soprattutto da Let’s Encrypt: permette a un software di creare un account presso una CA, richiedere un certificato, dimostrare automaticamente il controllo sul dominio, scaricare il certificato e rinnovarlo prima della scadenza.

Per gli amministratori la scelta ha una conseguenza interessante: un client ACME già compatibile con altre CA non dovrebbe richiedere un nuovo sistema di gestione: in molti casi sarà sufficiente configurare la directory URL della CA Cloudflare.

Il vero salto tecnico sono i Merkle Tree Certificates per guardare al post-quantum

La parte più innovativa del progetto riguarda la transizione verso certificati compatibili con una futura Internet post-quantum. Cloudflare intende emettere in produzione i primi Merkle Tree Certificates (MTC) nel primo trimestre del 2027.

Gli MTC non sono ancora uno standard definitivo: la proposta nasce dalla necessità di sostituire le firme classiche dei certificati X.509 con firme post-quantum molto più grandi.

La crittografia post-quantum comprende algoritmi progettati per resistere anche ad attacchi condotti con futuri computer quantistici, che potrebbero rendere vulnerabili sistemi oggi molto usati come RSA ed ECDSA. Il problema è che molti degli algoritmi post-quantum selezionati dagli standard moderni, come ML-DSA, richiedono chiavi pubbliche e firme di grandi dimensioni: una conseguenza delle strutture matematiche impiegate per ottenere sicurezza anche contro avversari quantistici.

Questi nuovi schemi possono aumentare pesantemente la quantità di dati scambiata durante il TLS handshake.

Il draft IETF sui Merkle Tree Certificates fa un esempio significativo: ML-DSA-44 usa chiavi pubbliche da 1.312 byte e firme da 2.420 byte; ML-DSA-65 sale rispettivamente a 1.952 e 3.309 byte. Sommando firme del certificato, catena e informazioni legate alla trasparenza, l’overhead può diventare di parecchi kilobyte per connessione.

Perché gli alberi di Merkle aiutano la crittografia post-quantum

L’idea alla base dei Merkle tree è più semplice di quanto sembri. Invece di firmare singolarmente ogni certificato con una firma post-quantum, che occupa molto più spazio rispetto alle firme crittografiche oggi più comuni, la CA raggruppa molte emissioni in una struttura verificabile e firma il risultato complessivo.

Per costruire questa struttura si parte dagli hash dei certificati. Gli hash sono combinati a coppie, poi nuovamente aggregati fino ad arrivare a un unico valore finale, chiamato radice dell’albero. Se anche un solo certificato cambia, cambia anche la radice: diventa quindi possibile accorgersi immediatamente di qualsiasi modifica.

Quando il browser deve verificare un certificato non ha bisogno di ricevere l’intero albero. Ottiene soltanto una piccola serie di hash, chiamata Merkle proof, sufficiente a dimostrare che quel certificato appartiene davvero all’insieme firmato dalla CA. In pratica, una sola firma post-quantum può contribuire a proteggere un gran numero di certificati, evitando di aggiungere una firma molto pesante a ciascuno di essi.

Il vantaggio è soprattutto nelle dimensioni e nell’efficienza del TLS handshake.

C’è poi un secondo aspetto importante. Nei Merkle Tree Certificates il registro delle emissioni non è un controllo aggiunto dopo la creazione del certificato: fa parte direttamente del meccanismo con cui il certificato acquista validità. Il progetto IETF prevede inoltre soggetti indipendenti che possono verificare e controfirmare lo stato dell’albero, rendendo più difficile per una CA presentare cronologie differenti a soggetti diversi.

Cloudflare prova a ripensare la CA per il Web che verrà

Il succo della questione non è soltanto che Cloudflare si stia preparando per aggiungersi all’elenco delle autorità in grado di emettere certificati TLS pubblicamente attendibili.

L’aspetto più interessante è il tentativo di costruire una CA pensando fin dall’inizio a ciò che oggi crea più problemi: automazione, rinnovi sempre più frequenti, gestione delle revoche e migrazione verso algoritmi resistenti ai futuri computer quantistici.

ACME rende l’emissione automatica; i Merkle Tree Certificates cercano invece di evitare che il passaggio alle firme post-quantum faccia crescere troppo il peso del TLS handshake. Sono due temi diversi, ma vanno nella stessa direzione: ridurre il lavoro manuale e rendere più sostenibile la gestione dei certificati.