eMudhra revoca altre otto CA: l’errore Python travolge la sicurezza dei certificati HTTPS

🛡️ Executive Summary

• eMudhra revoca altre otto autorità di certificazione intermedie. Le chiavi RSA non risultano crittograficamente deboli, ma la società non può dimostrarne la corretta gestione durante una procedura eseguita nell’aprile 2025.
• Il problema nasce da uno script Python utilizzato per trasferire chiavi tra HSM. Lo stesso processo aveva prodotto otto chiavi ECDSA ridotte a valori di un solo byte, scoperte e revocate a ottobre.
• La crisi si estende ai certificati utilizzati dai clienti. Sono coinvolti 195 certificati censiti dall’azienda, mentre Microsoft prevede di rimuovere altre dieci root eMudhra dal 16 novembre 2026.

La crisi crittografica di eMudhra si allarga: altre otto autorità di certificazione intermedie sono state revocate dopo che un’indagine interna ha individuato problemi nella gestione delle chiavi RSA precedentemente dichiarate non coinvolte nell’incidente di ottobre. Il nuovo sviluppo emerge dal rapporto pubblicato dalla società indiana nel sistema di segnalazione di Mozilla, dove la vicenda è seguita attraverso il bug 2083449. La stessa procedura Python che aveva generato otto chiavi ECDSA estremamente deboli aveva infatti trattato anche il materiale privato delle chiavi RSA, esponendolo alla memoria di un processo eseguito sul computer utilizzato durante la cerimonia di generazione. Non esistono prove pubbliche che queste ultime chiavi siano state rubate o ricostruite da terzi, ma eMudhra non è in grado di dimostrare che siano state protette secondo le regole dichiarate nella propria Certification Practice Statement. Il risultato è una nuova serie di revoche, il coinvolgimento di certificati già emessi e un’accelerazione dell’abbandono del mercato dei certificati TLS pubblicamente attendibili.

Otto nuove revoche dopo le chiavi crittografiche compromesse a ottobre

La nuova decisione riguarda otto autorità intermedie basate su RSA, appartenenti alle gerarchie G2B e G2C, che si aggiungono alle otto CA ECDSA già revocate il 18 ottobre 2026. La differenza tra i due incidenti è determinante. Nel primo caso, le chiavi private ECDSA erano state ridotte a valori tanto piccoli da poter essere ricostruite attraverso pochissimi tentativi. Nel secondo, le chiavi RSA non hanno mostrato la stessa debolezza matematica, ma il loro trattamento durante la procedura di importazione ed esportazione non può essere ricostruito con sufficienti garanzie.

Il rapporto pubblicato nel bug Mozilla 2083449 colloca la revoca delle otto CA RSA al 7 novembre 2026, con motivazione cessationOfOperation, cioè cessazione dell’attività. Le otto CA ECDSA erano state invece revocate con il codice cACompromise. La distinzione ha suscitato interrogativi tra i partecipanti alla discussione pubblica, perché la questione non riguarda semplicemente la fine di un servizio, ma l’impossibilità di certificare la corretta protezione del materiale crittografico. La gravità del primo incidente era stata già ricostruita nell’approfondimento sulle otto chiavi eMudhra prevedibili e sul rischio per HTTPS.

Uno script Python ha trasformato chiavi ECDSA sicure in valori di un byte

L’origine dei problemi risale al 30 aprile 2025, quando eMudhra organizzò una cerimonia di generazione delle chiavi attraverso dispositivi Hardware Security Module (HSM) Utimaco. Le chiavi avrebbero dovuto essere trasferite verso altri HSM, prodotti da Crypto4A, presenti nelle infrastrutture statunitensi ed europee della società. Le limitazioni dell’interoperabilità tra dispositivi di produttori differenti spinsero il personale PKI a sviluppare uno script Python per effettuare operazioni di wrapping e unwrapping, cioè protezione crittografica, trasferimento e successiva ricostruzione degli oggetti contenenti le chiavi private.

Durante una prova di trasferimento, il codice recuperò le chiavi dai moduli hardware e le ricostruì a partire dal materiale letto. Una sola istruzione errata ridusse il valore privato delle otto chiavi ECDSA al loro primo byte, producendo copie estremamente deboli. I valori risultanti erano compresi tra 4 e 237, mentre le chiavi originali erano state generate correttamente. Le copie ricostruite conservarono però etichette quasi identiche a quelle degli oggetti originari: vennero quindi utilizzate per firmare e certificare le autorità intermedie. Il risultato fu una gerarchia formalmente valida, ma protetta da chiavi sostanzialmente indovinabili. La vicenda dimostra come un dispositivo hardware certificato non possa compensare automaticamente un errore del processo software che gestisce le chiavi.

Due cicli WebTrust non hanno individuato il problema

Uno degli aspetti più preoccupanti riguarda i controlli. Le chiavi deboli avevano continuato a produrre firme crittografiche formalmente valide, superando le verifiche ordinarie sui certificati. La cerimonia non prevedeva un controllo della forza effettiva dei valori privati ricostruiti né un confronto tra la chiave pubblica certificata e quella originariamente generata. In queste condizioni, i certificati hanno attraversato due cicli di audit WebTrust senza che l’anomalia fosse identificata.

Esisteva però un segnale precedente. Tra maggio e giugno 2025 erano comparsi errori nella firma delle Certificate Revocation List (CRL), gli elenchi utilizzati per comunicare quali certificati non debbano più essere considerati validi. Il problema venne risolto sostituendo la chiave utilizzata per firmare gli elenchi con quella corrispondente ai certificati pubblicati, cioè proprio la copia debole. Fu corretto il sintomo, non la causa dell’errore. L’episodio mostra perché i controlli descritti nelle linee guida ACN sulla gestione delle funzioni crittografiche non possano limitarsi alla scelta di algoritmi sicuri, ma debbano comprendere custodia delle chiavi, procedure, verifiche indipendenti e tracciabilità delle operazioni.

Le chiavi RSA non erano deboli, ma sono state esposte fuori dagli HSM

Il secondo fronte emerge quando eMudhra riesamina il trattamento delle otto chiavi RSA generate durante la stessa cerimonia. In ottobre la società aveva inizialmente sostenuto che queste chiavi avessero seguito un percorso differente e non fossero state coinvolte. La successiva ricostruzione ha invece mostrato che anche il materiale privato RSA era transitato nella memoria del processo Python eseguito sul computer della cerimonia. Tra i componenti interessati figuravano elementi critici della chiave, compresi l’esponente privato e uno dei fattori primi.

Non è stato dimostrato che un aggressore abbia avuto accesso a quella memoria. Il problema è un altro: i registri e gli artefatti conservati non permettono di ricostruire con certezza le condizioni in cui il materiale era stato trattato. La società non può quindi attestare il rispetto della sezione 6.2.6 della propria Certification Practice Statement, relativa al trasferimento delle chiavi private verso e dai moduli crittografici. Per precauzione ha scelto di revocare le otto CA, anche senza prove di compromissione effettiva. Si tratta di una decisione legata alla perdita di garanzie sulla catena di custodia, non alla scoperta di una seconda serie di chiavi banalmente ricostruibili.

Coinvolti 195 certificati, compresi siti universitari e organizzazioni

Il nuovo incidente presenta conseguenze operative differenti rispetto a quello di ottobre. Le otto CA ECDSA inizialmente compromesse non avevano emesso certificati destinati agli utenti finali. Alcune delle autorità RSA revocate a novembre, invece, erano state utilizzate in produzione a partire da maggio 2026. L’inventario citato nell’indagine comprende 195 certificati, dei quali 130 riconducibili a EM DV TLS CA – G2C, 63 a EM OV TLS CA – G2C e due alla CA per la firma del codice EM OV CS CA – G2C. Tra i titolari figurano anche università, istituti di formazione, altre organizzazioni e 29 certificati riferiti a domini eMudhra.

La società dichiara di aver completato la sostituzione dei certificati interessati, ma resta importante verificare eventuali dipendenze residue attraverso i log di Certificate Transparency e l’inventario delle applicazioni. Il caso amplifica le conseguenze dell’uscita di eMudhra dal mercato pubblico dei certificati SSL/TLS già annunciata a ottobre. Una compromissione delle CA, o l’impossibilità di dimostrare la corretta custodia delle loro chiavi, non riguarda soltanto i nuovi certificati: può imporre la sostituzione di quelli già distribuiti su server, applicazioni e servizi utilizzati quotidianamente.

Microsoft ritirerà altre dieci root eMudhra dal 16 novembre

La crisi investe direttamente i programmi di fiducia dei principali sistemi operativi e browser. Nel comunicato aggiornato il 10 novembre, Microsoft annuncia la rimozione delle dieci root eMudhra ancora presenti nel Microsoft Trusted Root Program, a partire dal 16 novembre 2026. Per Windows il cambiamento verrà distribuito attraverso i meccanismi automatici di aggiornamento delle autorità considerate attendibili, mentre Edge e WebView2 riceveranno aggiornamenti del componente dedicato ai metadati PKI. Le tempistiche degli altri prodotti Microsoft e dei sistemi che utilizzano archivi di fiducia differenti potranno variare.

Anche Mozilla e Apple hanno adottato misure per impedire che le catene compromesse vengano accettate. Su macOS, il problema riguarda anche strumenti da riga di comando come curl e git, che in alcune configurazioni utilizzano l’archivio /etc/ssl/cert.pem anziché i normali meccanismi di fiducia delle applicazioni Apple. La documentazione ufficiale di Apple distingue infatti i browser e le applicazioni protette automaticamente dagli strumenti che possono richiedere aggiornamenti specifici. Le conseguenze della rimozione delle CA sui servizi cloud erano già state esaminate nell’analisi della risposta AWS e dei certificati eMudhra.

La crisi eMudhra diventa un caso di governance della fiducia digitale

La società ha incaricato KPMG di condurre una revisione indipendente, con completamento previsto per il 4 dicembre 2026, mentre un inventario complessivo delle chiavi delle proprie CA è atteso entro il 30 novembre. Restano aperte domande sulla documentazione delle cerimonie, sui controlli effettuati dagli auditor, sull’utilizzo degli HSM al di fuori delle modalità approvate e sulle ragioni della scelta dei codici di revoca. La documentazione pubblica non dimostra un abuso delle chiavi RSA, ma conferma che il sistema di verifica e tracciabilità non è stato sufficiente a garantirne la corretta custodia.

Continua con: le otto chiavi eMudhra prevedibili individuate a ottobre e il ritiro dei certificati eMudhra e le conseguenze per HTTPS.

Il problema eMudhra non è soltanto un errore Python: è il fallimento di una catena di controlli che avrebbe dovuto impedire a chiavi deboli o non correttamente custodite di diventare autorità crittografiche considerate affidabili. Gli HSM hanno funzionato, i certificati hanno superato verifiche formali e le procedure sono rimaste operative per mesi. Ma nessuno di questi elementi è stato sufficiente a garantire che le chiavi certificate fossero quelle effettivamente previste. La revoca di sedici autorità intermedie e il progressivo abbandono dei trust store dimostrano quanto sia costoso ricostruire la fiducia una volta che le garanzie alla sua base vengono meno.