La settimana scorsa, durante una revisione architetturale in Romiltec, stavamo discutendo un tema apparentemente banale: quanto costa davvero mantenere affidabile la catena dei certificati quando hai decine, centinaia o migliaia di endpoint da proteggere. Non solo in euro, ma in rischio operativo, downtime, compliance e tempo del team. È qui che la notizia su Cloudflare, la sua nuova Certificate Authority pubblica e la crittografia post-quantistica diventa più di una curiosità di tecnologia: diventa una domanda concreta su come preparare HTTPS al prossimo ciclo di rischio.
Cloudflare ha annunciato l’intenzione di creare una CA pubblica capace di emettere sia certificati tradizionali sia Merkle Tree Certificates, o MTC, pensati per uno scenario post-quantistico. Il punto interessante non è solo “certificati resistenti ai computer quantistici”. Il punto è la migrazione: come si introduce una nuova forma di fiducia digitale senza rompere browser, dispositivi legacy, automazioni ACME e workflow già in produzione?
Tecnologia e contesto: una nuova CA pubblica per la transizione post-quantistica
Il problema della crittografia post-quantistica non è teorico per chi gestisce infrastrutture. Anche se la minaccia non si traduce automaticamente in un incidente domani mattina, le architetture di sicurezza hanno cicli di vita lunghi. Certificati, root store, dispositivi IoT, appliance aziendali e browser non si aggiornano tutti con la stessa velocità. Chi ha mai dovuto sostituire una chain TLS in ambienti enterprise sa che “basta aggiornare” è una frase pericolosa.
Cloudflare sta provando a posizionarsi direttamente dentro la Web PKI globale. Per ottenere riconoscimento immediato, l’azienda acquisirà da GlobalSign il materiale delle chiavi di una Root CA già pubblicamente attendibile. Secondo le informazioni disponibili, l’operazione dovrebbe concludersi nei due mesi successivi al 30/09/2026. In parallelo, Cloudflare ha presentato domanda per entrare nei programmi root di Chrome, Apple, Microsoft e Mozilla.
Questa doppia strada è significativa. Da un lato c’è la compatibilità con l’esistente, perché una Root CA già riconosciuta riduce l’attrito iniziale. Dall’altro c’è il percorso formale nei root program dei grandi ecosistemi browser e sistema operativo. In termini pratici, è una strategia per non trasformare la sicurezza post-quantistica in un esperimento isolato da laboratorio.
Merkle Tree Certificates: efficienza prima dell’hype
La parte più interessante, dal punto di vista tecnico, è la scelta dei Merkle Tree Certificates. Le firme post-quantistiche dirette avrebbero un costo pesante sull’handshake TLS: il riferimento parla di un aumento dei dati di circa 40 volte. In un mondo ideale questo sarebbe solo un dettaglio. In produzione, invece, significa più latenza, più banda, più complessità su reti mobili, edge, sistemi embedded e ambienti con connessioni instabili.
Gli MTC provano a spostare il problema. Invece di inserire direttamente tutto il peso della firma post-quantistica nell’handshake, permettono di verificare la registrazione del certificato in un registro attendibile tramite prove leggere. Il risultato atteso è mantenere i dati dell’handshake intorno ai 40 kB, un ordine di grandezza più vicino alle prestazioni attuali.
Questa è una scelta pragmatica. Non promette magia, promette una forma di compromesso ingegneristico: aumentare la sicurezza futura senza rendere ingestibile il traffico HTTPS di oggi. Cloudflare ha già condotto un esperimento con Chrome e Google, e prevede l’emissione di MTC in produzione a partire dal primo trimestre del 2027. I certificati, dettaglio non secondario per PMI e team con budget limitati, saranno gratuiti anche per chi non utilizza i servizi Cloudflare.
Le implicazioni strategiche per CTO, team IT e aziende
Quando una CA entra nel flusso operativo dei certificati, non sta vendendo solo crittografia. Sta entrando nella supply chain della fiducia. Per questo leggo l’annuncio di Cloudflare attraverso quattro principi operativi, più che come una semplice news di settore.
- La compatibilità legacy resta il vero collo di bottiglia. La presenza di una Root CA già attendibile può aiutare nella fase iniziale, ma ogni azienda ha ancora il proprio parco di browser, sistemi operativi, appliance e dispositivi IoT. La transizione post-quantistica dovrà convivere con asset che non si aggiornano rapidamente.
- La dimensione dell’handshake è un tema di business, non solo di protocollo. Se una soluzione aumenta troppo latenza e traffico, impatta conversioni, UX, costi cloud e stabilità del servizio. Gli MTC sono interessanti proprio perché provano a contenere questo overhead.
- La fiducia richiede osservabilità. Cloudflare parla di modello “Glass-Box”, build del codice riproducibili e dashboard pubbliche. È un segnale importante: nella Web PKI moderna non basta dire “fidatevi”, bisogna rendere ispezionabile il processo.
- L’automazione è la linea di difesa contro gli incidenti. Emissione, rinnovo e revoca manuale non scalano. L’uso di ACME e dei segnali di rinnovo automatizzato previsti dall’RFC 9773 indica una direzione precisa: sostituire certificati in background su milioni di siti riducendo il rischio di interruzioni.
Questo ultimo punto è spesso sottovalutato. Un certificato compromesso o da revocare non è solo un problema crittografico. È un problema di coordinamento. Se il workflow non è idempotente, osservabile e automatizzato, l’incidente diventa un outage.
Glass-Box, Certificate Transparency e memoria storica
Il riferimento alla trasparenza non è decorativo. Cloudflare intende integrare i registri di Certificate Transparency, unificando registrazione ed emissione. Questo approccio ha una radice precisa: la Web PKI ha imparato nel modo più duro che una CA non può essere una scatola nera.
La compromissione di DigiNotar nel 2011 resta uno degli esempi più citati quando si parla di vulnerabilità sistemiche nella fiducia digitale. Non serve usare quell’episodio come spauracchio, ma come promemoria architetturale: se una CA sbaglia, l’impatto può propagarsi ben oltre il singolo dominio.
Il modello Glass-Box, con build riproducibili e dashboard pubbliche, va nella direzione giusta perché riduce l’asimmetria informativa tra chi emette certificati e chi dipende da quei certificati. Da CTO, questo è il tipo di dettaglio che guardo prima del comunicato marketing. La governance batte lo slogan.
Applicazione pratica: cosa cambia nei workflow reali
In Romiltec, non cambierei una strategia TLS aziendale da un giorno all’altro solo perché arriva una nuova CA con un messaggio forte sul post-quantum. Prima farei una mappatura. Quali domini usano rinnovo automatico? Quali sistemi dipendono da chain certificate hardcoded? Dove abbiamo appliance, reverse proxy, CDN, ambienti staging e integrazioni enterprise che potrebbero comportarsi in modo diverso?
Un piano realistico potrebbe partire da tre livelli:
- Inventory dei certificati e delle dipendenze. Senza una mappa aggiornata di domini, chain, scadenze e sistemi coinvolti, ogni migrazione diventa un debug al buio.
- Test controllati su ambienti non critici. Gli MTC in produzione sono previsti dal primo trimestre 2027, quindi ha senso preparare oggi pipeline e monitoring, non improvvisare quando diventeranno disponibili.
- Verifica della compatibilità client. Browser moderni, dispositivi legacy e IoT non hanno lo stesso ritmo. La compatibilità va misurata nel proprio contesto, non dedotta da una slide.
Sul fronte economico, l’annuncio della gratuità dei certificati anche per chi non usa Cloudflare può ridurre una barriera per PMI e progetti con margini stretti. Ma attenzione: il costo del certificato non è l’unico costo. Restano costi di governance, test, automazione, audit e gestione delle eccezioni. Il ROI dipenderà dalla capacità di integrare il cambiamento nei workflow esistenti senza creare debito operativo.
Limiti e punti ancora da osservare
Ci sono aspetti su cui conviene rimanere prudenti. Le informazioni disponibili non bastano per valutare la reazione degli altri grandi player del settore o per prevedere quanto rapidamente browser e piattaforme completeranno l’adozione. È corretto osservare il movimento di Cloudflare, ma sarebbe prematuro dichiarare conclusa la transizione post-quantistica di HTTPS.
Inoltre, una CA pubblica deve essere giudicata nel tempo. Le promesse su trasparenza, dashboard e build riproducibili sono forti, ma il valore si vedrà nella gestione ordinaria: incident response, revoche, auditabilità, comunicazione durante problemi reali e compatibilità con ecosistemi complessi. La fiducia non si annuncia. Si mantiene.
Il vero segnale strategico, però, è chiaro: la crittografia post-quantistica sta uscendo dalla fase “paper e laboratorio” e sta entrando nella pipeline operativa di HTTPS. Non significa che ogni azienda debba migrare domani. Significa che ogni azienda dovrebbe iniziare a sapere dove sono i propri certificati, come vengono rinnovati e quanto è fragile la propria catena di fiducia.
La mia sintesi è semplice: Cloudflare sta provando a rendere la transizione post-quantistica compatibile con la realtà, non solo con la teoria. Per chi gestisce infrastrutture, questo è il momento giusto per fare inventory, automatizzare i rinnovi e rimuovere dipendenze opache. La domanda non è se HTTPS cambierà. La domanda è: il tuo stack sarà pronto quando quel cambiamento diventerà operativo?