Otto chiavi di CA di eMudhra sono state compromesse. Ecco cosa significa per te

Otto CA intermedie di eMudhra sono state create con chiavi private che chiunque può recuperare dal certificato pubblico. I browser le hanno bloccate entro poche ore dalla segnalazione del 17 ottobre, e i certificati ora sono revocati. Abbiamo controllato ogni inventario in Red Sift Certificates e Hardenize e contattato gli account coinvolti: quelli con certificati emessi dalle otto CA e quelli con certificati sotto la emSign ECC Root CA - G3, che Firefox e Chrome stanno rimuovendo. Se gestisci qualcosa che comunica in TLS senza un browser davanti, aggiorna i tuoi trust store.

eMudhra, la CA indiana dietro il marchio emSign, ha creato otto nuove CA intermedie il 30 aprile 2025: sei per i certificati TLS e due per la firma del codice. Un mese dopo, Sectigo ha apposto la firma incrociata su tutte e otto con la sua root AAA Certificate Services, quindi ogni chiave compare in due certificati che condividono lo stesso Subject Key Identifier.

Nessuno ha dovuto rubare queste chiavi. Ognuna è una chiave a curva ellittica P-384 il cui valore segreto è inferiore a 256, e per una di esse è il numero 4. Con il certificato in mano, si può recuperare la chiave privata su un portatile in molto meno di un secondo, provando un valore dopo l'altro. eMudhra non ha ancora confermato la causa principale. Secondo la sua spiegazione preliminare, un difetto nello script della key ceremony ha generato una seconda coppia di chiavi, debole, accanto a quella robusta, e la coppia debole è finita nelle richieste di certificato perché le etichette si somigliavano.

Un ricercatore ha segnalato il problema ai root program dei browser il 17 ottobre 2026, con un messaggio firmato da tutte e otto le chiavi come prova. Queste sono le CA intermedie coinvolte. Ogni hash rimanda alla relativa voce su crt.sh.

• 17 ottobre. Un ricercatore ha segnalato le chiavi ai root program dei browser. Nel giro di poche ore, Chrome e Firefox hanno distribuito aggiornamenti che indicano a ogni browser installato di rifiutarle, senza bisogno di una nuova versione del browser o di un riavvio.
• 18 e 19 ottobre. Prima eMudhra, poi Sectigo hanno revocato i certificati. Apple ha distribuito lo stesso blocco su iOS e macOS.
• 20 ottobre. Windows ha seguito. Mozilla ha pubblicato i dettagli e rimosso la emSign ECC Root CA - G3 da Firefox; Chrome ha annunciato che farà lo stesso. Mozilla mantiene la root RSA emSign Root CA - G1, che Chrome sta ancora valutando.

La buona notizia è che prima del blocco non è stato emesso nulla sotto queste CA. Google ha confermato che nessun certificato con catena verso di esse è mai stato registrato in Certificate Transparency, ed eMudhra afferma di non aver emesso alcun certificato per i clienti.

Chrome, Safari, Firefox ed Edge per desktop rifiutano un certificato TLS privo di prova CT, quindi nessuno di loro avrebbe potuto accettare un falso. Questa protezione però non è universale. Mozilla sta ancora lavorando a un problema con Firefox per Android 158.0.1, e i client che non applicano CT non ne beneficiano affatto. Dalla divulgazione, i ricercatori hanno registrato oltre 100.000 certificati dimostrativi con queste chiavi, compresi falsi per google.com. Ecco quanto poco sforzo serve.

• Hai un certificato emesso da una delle otto CA. La CA intermedia emittente è revocata, quindi la catena non è più attendibile e i browser la rifiutano. Sostituiscilo. Secondo eMudhra questo gruppo è vuoto; verifica il tuo inventario invece di fidarti sulla parola.
• Hai un certificato con catena verso la emSign ECC Root CA - G3. Non è compromesso, ma Firefox non considera più attendibile quella root e Chrome smetterà presto di farlo. Secondo la stima iniziale di eMudhra, circa 30.000 certificati devono passare alla sua root RSA, emSign Root CA - G1, che Mozilla mantiene. Fai riemettere il tuo prima che la modifica di Chrome raggiunga i tuoi utenti.
• Il tuo software si connette ad altri server tramite TLS. Cioè, tutti. curl, Python, Node.js, Go, Java, i runner CI, i client API, il TLS reciproco e i dispositivi embedded si affidano a un bundle di certificati su disco e per lo più non verificano né la revoca né CT. Un ricercatore ha falsificato un certificato per una nota API di pagamento, e curl, Python e Node.js lo hanno accettato tutti con le impostazioni predefinite. Finché i tuoi bundle non saranno aggiornati, lo accetteranno anche i tuoi client.
• Verifichi software Windows firmato. I certificati di firma del codice non vengono registrati in CT, quindi nessuno può elencare cosa è stato firmato con le due CA di firma del codice. eMudhra afferma che non è stato firmato nulla, ma le chiavi sono deboli dal 30 aprile 2025, quindi un timestamp non dimostra niente. Considera non attendibile tutto ciò che è stato firmato con esse.

Il 21 ottobre abbiamo cercato in ogni inventario di Red Sift Certificates e Hardenize i certificati emessi con le otto chiavi, confrontando l'identificatore di chiave dell'emittente e gli hash di catena di tutti e sedici i certificati. Ne abbiamo trovati una manciata, nessuno su un servizio in produzione, tutti registrati dopo la divulgazione da ricercatori che testavano le chiavi recuperate. Abbiamo anche cercato i certificati sotto la root ECC G3. Abbiamo contattato ogni account di entrambi i gruppi.

Puoi verificarlo da solo. Il widget Certificate Authorities nella tua dashboard, qui sotto, elenca le CA da cui provengono i tuoi certificati. Se compare eMudhra, apri quei certificati, confronta lo SHA-256 della CA emittente con la tabella qui sopra e controlla in quale root termina la catena. Sono compromessi solo i certificati emessi dalle otto CA intermedie. I certificati sotto la root ECC G3 non lo sono, ma dovranno essere riemessi. Anche i certificati InCommon emessi da aprile 2026 risultano come eMudhra, perché le loro CA intermedie sono emesse sotto la root G1 di eMudhra; non richiedono alcun intervento.

• Aggiorna i trust store ovunque. Aggiorna i pacchetti CA del sistema operativo, Python certifi, Node.js, Java cacerts, Homebrew e i trust store inclusi nelle applicazioni. Ricompila i binari Go con una toolchain aggiornata e i container con immagini di base e dipendenze aggiornate, poi esegui di nuovo il deploy.
• Blocca le CA compromesse. Controlla mTLS, VPN, gateway API e pin dei certificati. Rifiuta le chiavi coinvolte sia nelle catene eMudhra sia in quelle con firma incrociata di Sectigo; eliminare una CA intermedia in cache non basta.
• Fai riemettere i certificati con catena verso la emSign ECC Root CA - G3. Sostituiscili con certificati con catena verso una root attendibile prima che la modifica di Chrome raggiunga i tuoi utenti.
• Mantieni attiva la verifica. Analizza gli errori di certificato dopo gli aggiornamenti invece di disattivare i controlli.
• Testa il percorso reale. Verifica che l'applicazione effettiva rifiuti le catene compromesse. Un test con il browser o con curl sul portatile non dimostra che un servizio in produzione sia protetto.
• Individua i dispositivi che non puoi aggiornare. Limita il loro accesso alla rete. Dove possibile, usa un gateway aggiornato che termini il TLS e convalidi i certificati upstream. Un firewall da solo non basta.

Red Sift Certificates mantiene un inventario in tempo reale di ogni certificato del tuo parco, con la catena effettivamente inviata da ciascun server, così un incidente legato a una CA diventa una semplice ricerca anziché una corsa contro il tempo. Il widget Certificate Authorities mostra da quali CA dipendi, e il monitoraggio di Certificate Transparency ti avvisa quando viene emesso un nuovo certificato per i tuoi domini e da chi.

Se non sei ancora cliente di Red Sift Certificates e vuoi sapere se qualche certificato dei tuoi domini ha una catena verso queste CA, richiedi una demo gratuita.

• eMudhra Intermediate CA Compromise: pagina di divulgazione e sito di test
• Mozilla Security Blog: Protecting Firefox users following the compromise of eMudhra intermediate certificates
• Mozilla dev-security-policy: Compromised eMudhra Intermediate Certificates (include la dichiarazione del Chrome Root Program)
• Bugzilla 2083449: Private key compromise of eMudhra Intermediate Certificates
• Cloudflare: 8 eMudhra certificates are compromised. Here's what you need to know
• Scott Helme: Eight bits of trust, eMudhra's CA keys cracked in milliseconds