La sicurezza di Internet si fonda su un meccanismo che utilizziamo ogni giorno senza pensarci: la fiducia. Quando ci colleghiamo a un sito HTTPS, il nostro browser verifica un certificato digitale e riconosce un’identità attraverso una catena di autorità considerate affidabili.
Ma cosa succede quando una delle organizzazioni incaricate di garantire questa fiducia produce chiavi crittografiche che chiunque potrebbe ricostruire?
È quanto emerso il 20 ottobre 2026, quando Ars Technica ha riportato la scoperta di otto certificati intermedi appartenenti alla Certification Authority indiana eMudhra, associati a chiavi private di una debolezza difficilmente immaginabile.
Parliamo di valori come 4, 56, 66, 115, 155, 156, 230 e 237. Numeri che, in condizioni normali, avrebbero dovuto essere scelti casualmente all’interno di uno spazio crittografico di circa 384 bit, composto da un numero di possibilità praticamente inesplorabile.
In questo caso, invece, bastavano poche centinaia di tentativi per ricostruire le chiavi.
Indice degli argomenti
Il problema non è TLS, ma chi garantisce la fiducia
La vulnerabilità non deriva dalla scoperta di un nuovo attacco contro gli algoritmi crittografici utilizzati nelle connessioni TLS. Il problema è molto più concreto: durante la generazione delle chiavi private qualcosa è andato storto, producendo valori estremamente prevedibili.
La gravità dell’incidente dipende anche dalla tipologia dei certificati coinvolti. Non erano semplici certificati associati a singoli siti web, ma certificati di autorità intermedie, che possono essere utilizzati per emettere ulteriori certificati digitali.
Se un attaccante dispone della chiave privata di un’autorità intermedia ancora considerata affidabile, può potenzialmente produrre certificati falsi per domini che non controlla, impersonando servizi legittimi e intercettando comunicazioni quando riesce a posizionarsi nel percorso del traffico.
Sei delle otto autorità coinvolte erano abilitate all’emissione di certificati TLS, mentre le altre due erano destinate alla firma del codice.
La scoperta è arrivata grazie a un ricercatore indipendente, identificato come Wayne, che ha dimostrato di poter ricostruire una delle chiavi firmando digitalmente un messaggio. Una prova sufficiente a far scattare l’intervento dei principali operatori dell’ecosistema WebPKI.
HSM certificati e audit: perché nessuno se n’è accorto?
Il dettaglio più interessante emerge dalle dichiarazioni ufficiali di eMudhra del 21 ottobre.
Le chiavi erano state generate il 30 aprile 2025 attraverso una procedura formalizzata, utilizzando Hardware Security Module certificati FIPS 140-2 Level 3, dispositivi progettati per proteggere le operazioni crittografiche e il materiale segreto.
Secondo la ricostruzione preliminare, una modifica autorizzata alla procedura, finalizzata a verificare operazioni di esportazione e reimportazione delle chiavi, avrebbe provocato la creazione di un secondo insieme di chiavi deboli. Queste ultime sarebbero state successivamente utilizzate per le richieste di certificazione, anche a causa della somiglianza tra le etichette identificative delle chiavi.
L’azienda ha inoltre dichiarato che le autorità interessate avevano superato audit indipendenti per due anni consecutivi.
Abbiamo quindi una procedura formalizzata, hardware certificato, personale esperto e verifiche indipendenti. Nonostante questo, chiavi crittografiche sostanzialmente inutilizzabili dal punto di vista della sicurezza sono entrate nella catena di fiducia.
È importante distinguere la conformità del dispositivo dalla correttezza dell’intero processo. Un HSM certificato non garantisce che ogni operazione eseguita attraverso di esso produca risultati sicuri, soprattutto quando intervengono script, configurazioni, procedure operative e scelte umane.
Allo stesso modo, un audit non costituisce una garanzia assoluta sull’assenza di vulnerabilità, ma deve essere valutato rispetto al perimetro e alla profondità dei controlli effettuati.
Resta però una domanda: come è possibile che nessuna delle verifiche abbia intercettato chiavi private con valori così evidentemente anomali?
I segnali erano già comparsi nel 2025
La vicenda presenta un ulteriore elemento che merita attenzione.
Nel giugno 2025, un precedente incidente documentato su Mozilla Bugzilla aveva già evidenziato problemi nelle liste di revoca dei certificati, le cosiddette CRL, relative a sei delle autorità intermedie oggi coinvolte.
Quelle liste erano state firmate utilizzando chiavi non corrispondenti a quelle associate ai rispettivi certificati, rendendo impossibile verificarne correttamente le firme digitali.
All’epoca il problema era stato trattato come un errore operativo nella configurazione delle chiavi e successivamente risolto. Nella nuova indagine, eMudhra ha spiegato che quelle CRL erano state inizialmente firmate con le chiavi originali, considerate corrette, e poi rigenerate utilizzando le chiavi deboli associate ai certificati effettivamente emessi.
Questo non significa che nel 2025 fosse già stata identificata la vulnerabilità crittografica. Significa però che esisteva un’anomalia concreta nella gestione delle identità crittografiche, oggi riconducibile allo stesso insieme di autorità intermedie.
Il punto non è stabilire con il senno di poi che ogni incidente avrebbe dovuto essere evitato. È comprendere se i processi di analisi delle anomalie siano realmente progettati per individuare problemi sistemici oppure soltanto per correggere il singolo malfunzionamento osservato.
La risposta dei browser e il problema dei sistemi dimenticati
Google e Mozilla hanno reagito rapidamente, distribuendo aggiornamenti delle rispettive liste di blocco per impedire ai browser di riconoscere le autorità compromesse.
Google ha inoltre precisato che, prima dell’intervento, non risultavano certificati TLS emessi dalle sei autorità interessate nei registri Certificate Transparency. Questo elemento impediva l’utilizzo di eventuali certificati fraudolenti nei client che applicavano obbligatoriamente tali controlli.
La stessa eMudhra ha dichiarato che nessuna delle otto autorità coinvolte aveva emesso certificati finali destinati agli utenti, pur essendone stata attivata una in produzione.
Non risultano quindi, allo stato delle informazioni pubbliche, prove di un utilizzo malevolo delle chiavi compromesse. Sarebbe scorretto trasformare un rischio critico in una violazione generalizzata già avvenuta.
Il problema, tuttavia, non termina con l’aggiornamento dei browser.
Applicazioni aziendali, sistemi Linux, dispositivi IoT, container e software che utilizzano archivi di certificati indipendenti potrebbero continuare a riconoscere catene di certificazione non più affidabili, finché non ricevono e applicano gli aggiornamenti necessari.
Cloudflare ha confermato di aver dovuto intervenire su client, servizi Zero Trust, componenti applicativi e ambienti containerizzati. L’operazione ha richiesto anche riavvii e nuovi deployment per rendere effettivi gli aggiornamenti.
La rimozione della fiducia nella root interessata introduce inoltre conseguenze operative per certificati legittimi emessi da altre autorità intermedie collegate alla stessa radice. Secondo le informazioni comunicate da eMudhra nel procedimento Mozilla, circa 30.000 certificati necessitano di migrazione verso una diversa catena di certificazione.
La sicurezza di una connessione, dunque, non dipende soltanto dalla presenza di un certificato valido, ma dalla capacità dell’intero ecosistema di riconoscere quando quella fiducia deve essere revocata.
La fiducia digitale deve essere verificabile, non soltanto certificata
Questo incidente offre una riflessione che va oltre il funzionamento delle Certification Authority.
Nella cyber security aziendale tendiamo spesso ad attribuire grande importanza a certificazioni, dichiarazioni di conformità e audit dei fornitori. Sono strumenti indispensabili, ma diventano pericolosi quando vengono interpretati come dimostrazioni definitive della sicurezza di un’organizzazione o di un servizio.
La lezione è particolarmente rilevante per chi governa la sicurezza della supply chain tecnologica.
Un’organizzazione può avere tutti i propri sistemi correttamente configurati e utilizzare protocolli crittografici robusti, ma continuare a dipendere dalla correttezza di componenti e servizi esterni sui quali non esercita un controllo diretto.
Per un CISO diventa quindi necessario conoscere le dipendenze crittografiche dei propri sistemi, verificare come vengono aggiornati gli archivi delle autorità attendibili e accertare che la revoca di un certificato compromesso sia effettivamente recepita dalle applicazioni.
Non basta sapere che un fornitore dispone di certificazioni. Occorre comprendere cosa sia stato verificato, quali controlli siano realmente operativi e quanto velocemente sia possibile reagire quando una garanzia di sicurezza viene meno.
Il caso eMudhra dimostra che anche una tecnologia crittografica estremamente robusta può essere vanificata da errori nella sua implementazione e nella governance dei processi.
La fiducia digitale non si rompe necessariamente quando qualcuno riesce a violare la crittografia. A volte, basta che nessuno abbia verificato ciò che avrebbe dovuto proteggere.
Partecipa alla community