Mozilla ha recuperato autonomamente le chiavi private di otto certificati intermedi di eMudhra il 17 ottobre 2026; l’azienda li ha revocati il giorno successivo. Sei erano intermediari TLS, usati per la sicurezza delle connessioni web, e due servivano alla firma del codice. La compromissione riguardava le chiavi generate con una procedura difettosa, non una vulnerabilità dell’algoritmo P-384.
Le otto chiavi e la cerimonia di generazione
Le chiavi provenivano da una cerimonia di generazione del 30 aprile 2025, che produsse un gruppo di 24 autorità di certificazione subordinate. Un’autorità intermedia collega una radice di fiducia ai certificati finali usati, per esempio, dai siti web o per firmare software.
Secondo il registro dell’incidente di Mozilla, gli otto valori privati P-384 erano interi inferiori a 256 e si potevano recuperare quasi istantaneamente. Mozilla li recuperò in modo indipendente. Il problema era quindi nella generazione delle chiavi: i valori risultavano troppo piccoli, nonostante il tipo di chiave P-384.
Nella ricostruzione preliminare di eMudhra, una deviazione durante un test di wrap/unwrap generò una seconda coppia di chiavi debole; etichette simili contribuirono poi a farla usare nelle richieste di firma dei certificati (CSR).
Che cosa ha dichiarato eMudhra sull’impatto
eMudhra ha dichiarato che nessuno degli otto intermediari emise certificati finali: sette non furono mai usati in produzione e l’unico impiegato in produzione non ne emise. Separatamente, l’azienda ha riferito che la sfiducia nella radice ECC associata colpì l’ecosistema di un cliente negli Stati Uniti, i cui certificati erano in fase di sostituzione.
Un’istantanea dei dati di Certificate Transparency, citata nel registro di Mozilla e riferita al 21 ottobre 2026, contava circa 30.800 precertificati non scaduti collegati alla radice emSign ECC Root CA - G3. Un precertificato è una registrazione preliminare di un certificato nei log pubblici. Di quei record, 30.791 erano stati emessi da due autorità subordinate di Internet2/InCommon e 18 da intermediari eMudhra.
Che cosa controllare nei software TLS
La revoca degli intermediari non basta a uniformare la gestione dei certificati in ogni programma: applicazioni diverse possono usare archivi di fiducia e procedure di revoca differenti. Cisco Talos raccomandava agli operatori di aggiornare i software che gestiscono connessioni TLS e i relativi archivi di certificati, controllando il percorso di validazione adottato da ciascun sistema.
Talos indicava Go 1.27.3 e 1.26.10 come versioni capaci di filtrare le catene di certificati contenenti gli hash degli otto intermediari. Al 21 ottobre 2026, alle 14:00 UTC, Talos dichiarava di non aver osservato incidenti dolosi in circolazione che coinvolgessero i certificati.
