Gli eMudhra certificati compromessi sono otto certificati intermedi di un'autorità di certificazioneAutorità di certificazione (CA): organizzazione che firma i certificati digitali con cui un sito dimostra la propria identità ai browser. indiana, le cui chiavi privateChiave privata: il segreto che permette di firmare. Chi la possiede può emettere certificati a nome della CA. erano così banali da poter essere ricavate in meno di un secondo: una di esse era il numero 4. Chi possiede queste chiavi può creare certificati falsi per qualsiasi sito. Chrome, Firefox, Apple e Microsoft hanno bloccato i certificati entro tre giorni dalla segnalazione e nelle fonti consultate non risultano abusi confermati. Restano però esposti i software che non aggiornano da soli le liste di fiducia.
🔐 Se hai solo un minuto: aggiorna browser, sistemi e librerie, poi controlla se i tuoi certificati risalgono a eMudhra o a emSign.
eMudhra certificati compromessi: la cronologia dei fatti
Il caso si è svolto in pochi giorni, ma ha radici in una procedura di generazione delle chiavi eseguita più di un anno prima. Ecco gli eventi principali, in ordine cronologico (gli orari, dove indicati, sono in UTC).
| Data | Che cosa è successo |
|---|---|
| 30 aprile 2025 | eMudhra genera le otto chiavi in una key ceremonyKey ceremony: procedura formale e documentata con cui una CA genera le proprie chiavi, di solito dentro moduli hardware sicuri (HSM).. Secondo la società, un difetto in un passaggio di wrap/unwrap produce una seconda serie di chiavi deboli accanto a quelle corrette, e sono le deboli a finire nei certificati pubblicati. |
| 17 ottobre 2026, 18:05 | Il Chrome Root Program riceve la segnalazione di un ricercatore. Mozilla la riceve alle 20:06. |
| 17 ottobre, 19:45 | Chrome blocca i sei intermedi usati per i siti web con un aggiornamento CRLSetCRLSet: lista di revoche d'emergenza che Chrome scarica da solo, senza aggiornare né riavviare il browser. Firefox usa uno strumento analogo, OneCRL.. |
| 17 ottobre, 22:59 | Il blocco di Mozilla (OneCRL) raggiunge i Firefox con impostazioni standard. |
| 18 ottobre | eMudhra revoca tutti e otto i certificati intermedi. |
| 19 ottobre | Apple blocca i certificati. Android riceve un blocco equivalente tramite Google Play Services. |
| 20 ottobre | Microsoft blocca i certificati. Mozilla e Google rendono pubblico il caso, Mozilla toglie la radice emSign ECC Root CA - G3 dal proprio elenco e il linguaggio Go rilascia aggiornamenti di emergenza. |
| 21 ottobre | Il CERT-In indiano pubblica l'advisory CIAD-2026-0050. eMudhra spiega la causa in un comunicato alle borse indiane e il ministero indiano MeitY istituisce un gruppo di indagine. |
| 22 ottobre | eMudhra annuncia che uscirà dal mercato globale dei certificati SSL/TLS. |
| 27 ottobre (previsto) | Google rimuove la radice emSign ECC Root CA - G3 dal Chrome Root Store, secondo il CERT-In e Google. |
Quanto al danno, il quadro disponibile è rassicurante ma non definitivo. Secondo eMudhra, nessuno degli otto intermedi ha emesso certificati per siti o utenti e uno solo era in produzione. Google ha inoltre riferito che, prima del blocco, nei registri di Certificate TransparencyCertificate Transparency (CT): registri pubblici in cui vengono annotati i certificati emessi. Chrome e altri browser rifiutano i certificati non registrati. non c'era alcun certificato TLS legato ai sei intermedi. Il CERT-In precisa che, al 21 ottobre, le informazioni pubbliche non provano uno sfruttamento malevolo. Nessuna fonte, però, indica un modo per escludere abusi passati oltre a quella ricerca nei registri, che copre solo i certificati registrati.
Perché una chiave privata uguale a 4 è un disastro
Le otto chiavi usano la curva ellittica P-384P-384: curva ellittica standard usata per le firme digitali. È solida, ma solo se la chiave è un numero davvero casuale.. Una chiave generata bene è un numero casuale di 384 bit, cioè uno tra circa 10115 possibili: nessuno potrebbe mai provarli tutti. Qui, invece, le chiavi erano numeri interi minori di 256. Il CERT-In sottolinea che il difetto non sta nell'algoritmo, ma nel modo in cui le chiavi sono state generate.
In pratica, partendo dalla chiave pubblica (che è scritta nel certificato) basta provare i valori uno alla volta finché uno combacia. I valori recuperati dai ricercatori sono 4, 56, 66, 115, 155, 156, 230 e 237. Con un normale portatile l'operazione richiede meno di un secondo. Provaci anche tu: la demo qui sotto simula la ricerca.
La prova: indovinare le otto chiavi
Il programma prova i numeri da 1 a 256, uno dopo l'altro, e confronta ogni tentativo con la chiave pubblica.
Tentativi: 0 su 256
Fatto: tutte e otto le chiavi sono state trovate in 237 tentativi. Per una chiave P-384 generata correttamente ne servirebbero circa 10115.
Le conseguenze sono concrete. Con la chiave di un intermedio, un attaccante può firmare un certificato per qualunque dominio, e il certificato risulterebbe valido a chi si fida di quella CA. È la base di un attacco man-in-the-middleMan-in-the-middle: l'attaccante si inserisce nel percorso di rete tra utente e sito (per esempio in un Wi-Fi pubblico) e legge o altera i dati in transito., che però richiede di trovarsi nel percorso di rete della vittima. Due degli otto intermedi servivano inoltre a firmare codice: in quel caso il rischio è far passare software malevolo per software di un editore fidato.
Come funziona la catena di fiducia: simulatore
Un browser non conosce il tuo sito: si fida di un elenco di radiciRadice (root): il certificato di partenza della catena di fiducia. Browser e sistemi operativi ne conservano un elenco, detto trust store. e verifica che il certificato del sito discenda da una di esse, passando per uno o più intermedi. Se una chiave di quella catena è nota a un attaccante, la fiducia crolla. Per questo i produttori hanno bloccato prima gli intermedi e poi la radice che li aveva firmati.
Il simulatore mostra che cosa succede nei diversi casi. Scegli il tipo di certificato e chi lo riceve. 👉 Nota come, per i certificati legittimi, la rimozione della radice abbia un effetto collaterale.
Simulatore della catena di fiducia
Chi è davvero a rischio
I browser moderni sono rimasti protetti per due motivi. Ricevono da soli le liste di revoca (CRLSet in Chrome, OneCRL in Firefox) e, inoltre, pretendono che i certificati siano registrati nei log di Certificate Transparency. Anche per questo il blocco è arrivato in poche ore, senza aggiornare né riavviare nulla.
Fuori dal browser, tuttavia, la situazione cambia. Strumenti da riga di comando, librerie, sistemi di build, comunicazioni tra server, container e dispositivi con una propria lista di CA spesso non controllano le revoche. Si fidano di un certificato finché non cambia il codice o il bundle di CA. Secondo la Internet Freedom Foundation, il ricercatore Scott Helme ha forgiato un certificato per l'host API di un grande gestore di pagamenti: curl, Python e Node.js lo hanno accettato con le impostazioni predefinite su Linux e macOS.
Va ricordato che lo sfruttamento richiede comunque un attaccante nel percorso di rete, e che Cloudflare dichiara di non aver trovato attacchi sui propri servizi. È un principio che conosciamo bene: quando un canale considerato affidabile viene compromesso, i controlli basati sulla fiducia non se ne accorgono, come nel caso Man in the Mail di Revolut.
Aggiornamenti e rimedi già disponibili
Molti progetti hanno risposto in fretta, in due modi: bloccando le otto chiavi nel codice oppure togliendo la radice dai bundle. Nella seconda ipotesi, però, anche i certificati legittimi emessi sotto quella radice smettono di essere accettati. Mozilla, Canonical e Red Hat hanno segnalato esplicitamente questo effetto collaterale.
| Software | Intervento |
|---|---|
| Firefox | Versione 158.0.1, ESR 115.43.1 e ESR 153.5.1: includono il blocco anche per chi non riceve gli aggiornamenti automatici delle liste. |
| NSS (Mozilla) | Versione 3.131.1: rimuove la radice emSign ECC Root CA - G3. |
| Go | Versioni 1.27.3 e 1.26.10: rifiutano ogni catena con una delle otto chiavi. Serve ricompilare i programmi. Go 1.25 e precedenti non sono più supportate. |
| Node.js | Versioni 26.12.1, 24.22.1 e 22.23.4: blocco delle otto chiavi e lista di radici aggiornata. |
| Python (certifi) | Versione 2026.10.19: la radice G3 esce dal bundle. |
| Ubuntu e Debian | Pacchetti ca-certificates aggiornati il 20 ottobre (USN-8944-1 e USN-8944-2 per Ubuntu, DSA-6572-1 per Debian 13). |
| Red Hat Enterprise Linux | Nessun pacchetto ancora disponibile al 21 ottobre. Il bollettino RHSB-2026-012 descrive un rimedio temporaneo che blocca due radici. |
⚠️ Le versioni indicate riflettono lo stato al 21 ottobre 2026 riportato da The Hacker News. Prima di intervenire verifica sempre il bollettino ufficiale del tuo fornitore, perché la situazione cambia di giorno in giorno. Nota anche che le immagini dei container vanno ricostruite dopo l'aggiornamento delle immagini di base.
Cosa fare subito: la checklist per chi gestisce sistemi
Le indicazioni seguono l'advisory del CERT-In e le raccomandazioni di Mozilla. Apri ogni passaggio per i dettagli.
1Aggiorna browser, sistemi operativi e applicazioni
Installa le ultime versioni di Chrome, Firefox e dei componenti Android, oltre agli aggiornamenti di sistema. Su Linux aggiorna il pacchetto ca-certificates. Dopo l'aggiornamento verifica che le catene interessate vengano effettivamente rifiutate dai client.
2Individua i certificati che risalgono a emSign o a eMudhra
Controlla gli emittenti dei certificati dei tuoi domini e dei servizi interni. Da terminale puoi elencare la catena presentata da un server:
openssl s_client -connect tuodominio.it:443 -servername tuodominio.it -showcerts </dev/null 2>/dev/null | grep -E "s:|i:"Cerca i nomi emSign ed eMudhra nelle righe di soggetto (s:) ed emittente (i:). Includi nell'analisi anche le catene con firma incrociata, come quelle che passano da Sectigo.
3Sostituisci i certificati che non saranno più fidati
Se un certificato risale alla radice emSign ECC Root CA - G3, ottienine uno nuovo da una gerarchia diversa e non toccata dal problema. Il CERT-In raccomanda di sostituire anche i certificati legittimi che i client smetteranno di accettare. eMudhra dichiara di fornire certificati sostitutivi ai clienti coinvolti.
4Aggiorna i bundle di CA indipendenti
Controlla applicazioni, runtime dei linguaggi, immagini dei container, librerie TLS, appliance di rete e dispositivi embedded che hanno una propria lista di CA. Applica gli aggiornamenti dei fornitori e, dove serve, ridistribuisci i componenti. Dove il software permette di bloccare singole chiavi o singoli intermedi, blocca gli otto interessati, come hanno fatto Go e Node.js.
5Non disattivare mai la verifica dei certificati
Davanti a un errore di certificato la scorciatoia più comune è spegnere i controlli. È la scelta peggiore, perché elimina proprio la protezione che gli aggiornamenti servono a ripristinare.
6Monitora i registri di Certificate Transparency
Tieni d'occhio i log pubblici e gli avvisi di sicurezza per scoprire certificati non autorizzati sui tuoi domini. Il monitoraggio affianca revoche e trust store, ma non li sostituisce.
7Controlla anche la firma del software
Due degli otto intermedi servivano per il code signing. Chi sviluppa o distribuisce software deve verificare la fiducia e lo stato di revoca delle catene di firma che usa, affiancando controlli aggiuntivi sull'integrità e sulla provenienza dei pacchetti.
Se vuoi un quadro completo delle dipendenze da certificati e fornitori nella tua azienda, un Cyber Audit è il punto di partenza più ordinato. E se rientri nella NIS2, ricorda che la gestione della crittografia e dei fornitori fa parte delle misure da governare: ne parliamo anche nell'articolo sulla scadenza NIS2 del 31 ottobre 2026.
Che cosa non è coinvolto
Il problema riguarda la gerarchia globale emSign, quella i cui certificati sono accettati dai browser. Secondo il CERT-In, i certificati di firma digitale e il servizio eSign regolati in India dal Controller of Certifying Authorities non sono toccati. La Internet Freedom Foundation, però, osserva che questa rassicurazione poggia sulla valutazione della stessa eMudhra e ha chiesto una verifica indipendente.
Dopo il caso: eMudhra esce dal mercato e cosa resta
Il 22 ottobre eMudhra ha annunciato l'uscita dal mercato globale dei certificati SSL/TLS. Motiva la scelta con l'attenzione ricevuta e con il peso marginale di quell'attività, circa l'1% dei ricavi. Continuerà a gestire le radici RSA G1 finché non avrà trasferito i clienti ad altre CA, senza costi per loro secondo quanto riportato, e manterrà attivi i servizi di revoca fino alla scadenza o alla sostituzione di tutti i certificati emessi. Nel frattempo il Chrome Root Program sta valutando la permanenza degli altri certificati di eMudhra, compresa la radice emSign Root CA - G1.
La lezione, in fondo, vale per tutte le aziende. La società ha dichiarato che radici e CA emittenti avevano superato audit indipendenti per due anni consecutivi, eppure nessuno aveva notato chiavi come il numero 4. Quindi un inventario aggiornato dei certificati, il monitoraggio dei registri pubblici e la capacità di sostituire in fretta un'autorità di certificazione contano più di qualsiasi rassicurazione. In sintesi, i casi di eMudhra certificati compromessi mostrano che la fiducia va verificata, non presupposta.
Glossario essenziale
- Autorità di certificazione (CA)
- Organizzazione che firma i certificati digitali e garantisce l'identità di siti, persone e software.
- Certificato intermedio
- Certificato di una CA che firma i certificati dei siti ed è a sua volta firmato dalla radice.
- Trust store
- Elenco di radici considerate affidabili da un browser, un sistema operativo o un'applicazione.
- Revoca
- Annullamento di un certificato prima della scadenza. Funziona solo se il software controlla le liste di revoca.
- HSM
- Modulo hardware sicuro in cui una CA genera e custodisce le proprie chiavi.
- Code signing
- Firma digitale del software, che ne attesta l'editore e l'integrità.
Domande frequenti su Google
Che cos'è eMudhra?
È una società di Bengaluru, quotata in Borsa in India, autorizzata dal Controller of Certifying Authorities a emettere firme digitali nel paese. Gestisce anche il marchio emSign, le cui radici sono presenti nei trust store di diversi browser e sistemi. Sul proprio sito dichiara di aver emesso oltre 60 milioni di certificati digitali.
Che cosa significa che una chiave privata era il numero 4?
Significa che la chiave, che dovrebbe essere un numero casuale enorme, era un numero minuscolo. Chiunque poteva ricavarla provando i valori in sequenza, in meno di un secondo, e usarla per firmare certificati falsi.
I miei dati sono a rischio?
Il rimedio pratico per gli utenti è tenere aggiornati browser e dispositivi e non ignorare mai gli avvisi di certificato: secondo eMudhra non c'è stata alcuna violazione di dati. Non risultano abusi confermati.
Come capisco se il mio sito usa certificati eMudhra?
Apri il certificato dal lucchetto del browser e leggi l'emittente, oppure usa il comando openssl s_client mostrato nella checklist. Se compaiono i nomi emSign o eMudhra, sostituisci il certificato con uno di un'altra gerarchia.
Il lucchetto HTTPS è ancora affidabile?
In generale sì. Il problema riguarda una CA specifica e i browser aggiornati hanno già bloccato i certificati interessati. Proprio la rapidità dei blocchi mostra come funziona il sistema quando i controlli sono attivi.
Un browser può togliere la fiducia a un'autorità di certificazione?
Sì. Mozilla, Google, Apple e Microsoft gestiscono programmi con regole precise e possono revocare o rimuovere una radice se la CA non dimostra competenza e rigore. Mozilla l'ha fatto il 20 ottobre per la radice emSign ECC Root CA - G3.
Domande frequenti
Quanti certificati sono stati emessi con le chiavi compromesse?
Secondo eMudhra nessuno degli otto intermedi ha emesso certificati per utenti o siti, e uno solo era in produzione. Google non ha trovato certificati TLS collegati ai sei intermedi nei registri CT prima del blocco. Chi aveva la chiave, tuttavia, poteva firmarne di propri senza chiederli a eMudhra.
Perché la revoca da sola non basta?
Perché funziona solo se il software controlla le liste di revoca. Molti strumenti non lo fanno, e per questo i produttori hanno anche rimosso la radice dai bundle e inserito il blocco delle chiavi direttamente nel codice.
Quando Chrome rimuove la radice emSign ECC Root CA - G3?
La rimozione dal Chrome Root Store è prevista per il 27 ottobre 2026 e, in Chrome Canary e Beta, anche prima. Mozilla l'ha già rimossa il 20 ottobre.
Che cosa devo fare se il mio sito usa un certificato emSign?
Installa prima di quella data (o subito, se è già passata) un certificato di un'altra gerarchia, perché i client che non si fidano più della radice mostreranno un errore. eMudhra dichiara di fornire certificati sostitutivi ai clienti coinvolti.
Le firme digitali indiane sono compromesse?
Il CERT-In afferma di no: i certificati di firma digitale e il servizio eSign regolati in India sono un'attività separata. La verifica indipendente di questa separazione è stata chiesta dalla Internet Freedom Foundation.
Resta aggiornato su cybersecurity e normative. Aggiungi Alchimie Digitali alle tue fonti preferite su Google: gli articoli di adigitali.it compariranno più spesso nelle notizie principali quando cerchi questi temi.
Aggiungi a Google ⭐Non sai se i tuoi certificati dipendono da emSign?
Se vuoi capire quali certificati, server e applicazioni della tua azienda dipendono da catene a rischio, e mettere in ordine trust store e procedure di sostituzione, possiamo aiutarti. Parti da una valutazione della cybersecurity aziendale o scrivici direttamente.
Fonti
- CERT-In, advisory CIAD-2026-0050, 21 ottobre 2026: cert-in.org.in
- Google, Protecting Chrome and Android users, 20 ottobre 2026: blog.google