Otto autorità di certificazione (CA) intermedie di eMudhra avevano chiavi private crittograficamente deboli, ricostruibili a partire dalle informazioni pubbliche dei rispettivi certificati. Il problema è stato segnalato il 17 ottobre 2026 e reso pubblico il 20 ottobre. Chi fosse riuscito a ricavare una di quelle chiavi avrebbe potuto firmare certificati HTTPS contraffatti per domini che non controllava, almeno nei client che continuavano a considerare attendibile la catena di certificazione.

La distinzione importante, emersa nelle comunicazioni ufficiali del 20 e 21 ottobre, riguarda l'origine dell'incidente. Allo stato delle indagini non risulta il furto di chiavi da server compromessi: è stata la loro generazione a produrre materiale crittografico prevedibile. Per l'infrastruttura di fiducia del web, il risultato è comunque grave. Una chiave di CA utilizzabile da terzi rende inaffidabili le firme che quella CA può produrre.

Cos'è successo alle CA di eMudhra

eMudhra opera nel mercato dei certificati digitali, anche attraverso il marchio emSign. Gli otto certificati interessati appartengono a CA intermedie di due famiglie, G3B e G3C: sei destinate all'emissione di certificati TLS (DV, OV ed EV) e due al code signing.

Una CA intermedia firma certificati per conto di una gerarchia che risale a una CA radice (root CA), presente negli archivi di fiducia di browser, sistemi operativi e librerie. Se la chiave privata di un'intermedia diventa ricostruibile, un attaccante può firmare un certificato apparentemente valido per un dominio altrui. Per sfruttarlo contro una vittima deve anche riuscire a presentarglielo durante la connessione, ad esempio controllando un percorso di rete o un endpoint di destinazione.

Il 17 ottobre un ricercatore identificato come Wayne ha dimostrato il problema firmando lo stesso messaggio con tutte e otto le chiavi. La prova è stata condivisa con i programmi di gestione delle CA attendibili. È un'evidenza più forte di un semplice sospetto: dimostra concretamente il possesso delle chiavi di firma.

Secondo la comunicazione ufficiale di eMudhra, i certificati furono creati durante una Key Generation Ceremony del 30 aprile 2025 con HSM certificati FIPS 140-2 Level 3. Un passaggio di key wrap/unwrap, usato per proteggere e recuperare materiale crittografico, avrebbe generato un secondo insieme di chiavi deboli accanto a quello corretto. Quello debole è finito nella gerarchia pubblicata. La causa tecnica precisa resta in indagine.

Il caso mostra un limite spesso trascurato: la certificazione di un HSM non garantisce che ogni operazione della procedura che lo circonda sia stata progettata e verificata correttamente. eMudhra afferma che il difetto è rimasto inosservato anche attraverso due cicli di audit indipendenti.

Cronologia e risposta dei produttori

Data Evento
30 aprile 2025 Generazione delle otto CA intermedie nella cerimonia di eMudhra.
17 ottobre 2026 Segnalazione tecnica ai root program; Chrome distribuisce un blocco tramite CRLSet e Firefox tramite OneCRL nello stesso giorno.
19 ottobre 2026 eMudhra revoca le otto CA. Apple adotta il blocco; Cloudflare avvia gli interventi sui propri servizi.
20 ottobre 2026 Divulgazione pubblica; Mozilla rilascia versioni correttive di Firefox e NSS, mentre altri ecosistemi aggiornano librerie e trust store.
21 ottobre 2026 eMudhra chiarisce il difetto nella procedura di generazione e comunica di non aver trovato evidenze di compromissione dei propri sistemi.
27 ottobre 2026 (previsto) Google prevede la distribuzione generalizzata della rimozione di emSign ECC Root CA - G3 dal Chrome Root Store.

Chrome ha distribuito il blocco usando gli hash SPKI delle chiavi pubbliche, non soltanto l'identità dei singoli certificati. È rilevante perché alcune delle intermedie esistono anche in versioni cross-signed, cioè firmate da una seconda gerarchia di certificazione. Un controllo basato sulla stessa chiave pubblica intercetta entrambe le varianti.

Mozilla ha fatto arrivare il blocco OneCRL alle normali installazioni Firefox senza chiedere agli utenti di riavviare il browser. Ha inoltre distribuito Firefox 158.0.1 e aggiornato NSS 3.131.1 per proteggere ambienti che non ricevono gli aggiornamenti dinamici.

Quanto era concreto il rischio?

La possibilità tecnica di produrre certificati falsi è confermata. Non equivale però alla prova che qualcuno li abbia effettivamente usati per intercettare traffico.

Google dichiara che nessun certificato TLS derivato dalle sei intermedie interessate era stato registrato nei log di Certificate Transparency prima del blocco. I client che applicano correttamente questa verifica, tra cui Chrome per i certificati pubblicamente attendibili, avrebbero quindi rifiutato un certificato contraffatto non registrato. Anche un attacco man-in-the-middle avrebbe incontrato quel controllo.

Molti servizi diversi dai browser, tuttavia, non impongono Certificate Transparency e non consultano sistematicamente le informazioni di revoca. È qui che il problema supera l'ambito della navigazione web: un servizio backend, un binario compilato tempo fa o un'applicazione che incorpora il proprio archivio di CA può continuare ad accettare una catena che il browser rifiuta.

eMudhra sostiene che sette delle otto intermedie non siano mai state usate in produzione e che l'unica distribuita non abbia emesso alcun certificato finale. La società dichiara anche che le chiavi private delle root CA e gli altri servizi di firma digitale non sono coinvolti. Sono elementi rassicuranti sul perimetro dichiarato dell'incidente, ma non risolvono retroattivamente il problema della fiducia nei client non aggiornati.

Perché revocare il certificato non basta

Una revoca funziona soltanto se il verificatore la conosce e la applica. Browser moderni possono ricevere blocchi centralizzati; applicazioni che usano bundle statici, immagini container o librerie TLS indipendenti spesso non hanno lo stesso meccanismo.

Di fronte a un'intermedia compromessa, i fornitori hanno seguito due strade: bloccare le chiavi specifiche oppure eliminare dal trust store la radice emSign ECC Root CA - G3. La seconda soluzione è più ampia e può interrompere connessioni legittime verso servizi ancora configurati con certificati che risalgono a quella radice.

Google ha annunciato che la rimozione della root dovrebbe raggiungere i dispositivi basati sul Chrome Root Store il 27 ottobre. Chi gestisce un server con quella catena deve sostituire il certificato con uno emesso da una gerarchia differente e ancora attendibile, senza aspettare che compaiano errori ai clienti.

Come verificare l'esposizione

Dennis Jackson, ingegnere di Mozilla, ha raccolto sul sito eMudhra Intermediate CA Compromise un test pubblico che presenta catene basate sulle intermedie compromesse. Da una macchina o da un container si possono effettuare due richieste, senza disabilitare la verifica TLS:

curl -Iv --max-time 10 https://dv-g3b-emudhra.we-have-a-problem.com/
curl -Iv --max-time 10 https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

Nel test, un errore di verifica del certificato è il risultato atteso: indica che quel percorso di validazione non considera affidabile la catena presentata. Se la connessione viene accettata, il client merita un'analisi immediata. La seconda richiesta esercita una catena alternativa cross-signed.

Il risultato vale solo per il client e per il percorso di verifica effettivamente utilizzati. Un curl aggiornato non certifica che siano protetti anche Java, Node.js, un'app Python, un binario Go o un container che includa un bundle autonomo.

Linux e container

Occorre identificare il pacchetto ca-certificates effettivamente distribuito e aggiornare le immagini base che ne incorporano una vecchia versione. Anche dopo l'aggiornamento dell'host, un container già costruito può conservare il precedente trust store. Per Ubuntu, Debian, Alpine e altre distribuzioni è disponibile un elenco delle versioni corrette, con i collegamenti agli advisory, nel registro tecnico mantenuto da Jackson.

Non conviene eliminare manualmente certificati da un trust store condiviso senza valutare gli effetti sulle connessioni legittime. In produzione, preferire pacchetti correttivi ufficiali e verificare le applicazioni dopo il redeploy.

Go, Python e librerie incorporate

Per Go sono state rilasciate le versioni 1.26.10 e 1.27.3, che rifiutano catene contenenti le chiavi compromesse. Aggiornare il compilatore non modifica automaticamente i binari già distribuiti: occorre ricompilare e distribuire nuovamente i servizi interessati.

Per Python, certifi 2026.10.19 rimuove dal proprio bundle la root coinvolta. Ma un'applicazione può usare il trust store del sistema, certifi, un bundle fornito da un'altra dipendenza o una configurazione esplicita. Verificare la versione di un pacchetto è soltanto il primo passo; va identificato quale archivio di CA usa davvero il processo.

Questi comandi aiutano a censire alcune componenti, senza modificare il sistema:

go version
python3 -m pip show certifi
cloudflared --version

Per Cloudflare Tunnel il produttore indica l'aggiornamento a cloudflared 2026.10.2. Cloudflare ha inoltre corretto propri prodotti e client WARP, precisando che chi amministra origin server, configurazioni mTLS e immagini container deve controllare separatamente i propri ambienti. Su Node.js, alla data del 21 ottobre, il blocco specifico risulta ancora in lavorazione: controllare gli advisory del progetto e il runtime effettivamente in uso.

Il problema per chi sviluppa servizi web

Pensiamo a un'app che interroga periodicamente un'API esterna. Il browser dell'utente può essere aggiornato, il sito pubblico può mostrare un lucchetto regolare, ma la richiesta server-to-server può attraversare un client TLS con un vecchio archivio di autorità attendibili. I meccanismi di revoca del browser non intervengono in quella connessione.

Per questo la verifica finale deve seguire il traffico reale dell'applicazione: identificare la libreria che convalida il peer, aggiornare il relativo store, ricostruire gli artefatti quando necessario e ripetere il test nel medesimo ambiente di esecuzione.

Un errore TLS comparso dopo la correzione non va aggirato con curl -k, verify=False o NODE_TLS_REJECT_UNAUTHORIZED=0. Si eliminerebbe proprio il controllo che impedisce di fidarsi di un certificato contraffatto.

Il punto che resta aperto è la verifica delle procedure di generazione delle chiavi nelle PKI. L'incidente eMudhra dimostra quanto una singola fase errata possa influenzare sistemi indipendenti, persino quando HSM e audit sono presenti. Il lavoro più urgente per chi gestisce software, però, è meno astratto: sapere quali autorità di certificazione considera attendibili ciascun client e poter aggiornare quella scelta rapidamente.

Fonti e aggiornamenti