Windows 11, aggiornamento straordinario: Microsoft rimuove certificati compromessi

Un problema nella generazione delle chiavi crittografiche di una Certification Authority (CA) ha costretto Microsoft a intervenire sui meccanismi di fiducia utilizzati da Windows, Edge e WebView2. Il motivo è particolarmente serio: alcune chiavi private appartenenti alla società eMudhra potevano essere ricostruite a partire dalle rispettive chiavi pubbliche. Un attaccante avrebbe quindi potuto creare certificati apparentemente legittimi, utilizzabili per impersonare siti Web o firmare codice malevolo.

La vicenda riguarda 8 autorità di certificazione intermedie della gerarchia eMudhra, 6 associate ai certificati TLS e due alla firma del codice secondo la classificazione adottata da Microsoft. Il 20 ottobre 2026 l’azienda di Redmond ha già distribuito le prime contromisure; adesso Redmond ha annunciato un intervento più esteso, con la rimozione di 7 certificati dalle liste di fiducia di Windows. Una misura straordinaria, che può avere conseguenze anche sui sistemi perfettamente aggiornati.

Il caso riporta l’attenzione su un elemento fondamentale della sicurezza informatica: la Public Key Infrastructure (PKI), l’infrastruttura che permette a sistemi operativi, browser e applicazioni di riconoscere certificati digitali attendibili. Il suo funzionamento presuppone che le chiavi private delle autorità di certificazione rimangano segrete. Se diventano ricostruibili, l’intera catena di fiducia rischia di perdere significato.

Microsoft rimuove 7 certificati dalle liste di fiducia di Windows

Nel comunicato pubblicato dal Microsoft Security Response Center (MSRC), l’azienda spiega di aver predisposto un aggiornamento straordinario, distribuito fuori dal normale ciclo mensile delle patch, per eliminare 7 certificati associati all’incidente occorso nei giorni scorsi.

Non si tratta semplicemente di bloccare alcuni certificati compromessi: Microsoft ha deciso di revocare la fiducia predefinita a una parte più ampia della gerarchia di certificazione interessata dall’incidente. Tradotto, significa che anche un certificato la cui chiave privata non risulta compromessa può incontrare problemi di validazione se è stata gestita per tramite dell’infrastruttura eMudhra.

Come è stato possibile ricostruire le chiavi private eMudhra

L’aspetto tecnicamente più interessante emerge dalle spiegazioni pubblicate dalla stessa eMudhra e dall’avviso del CERT-In indiano. L’incidente risale a una procedura di generazione delle chiavi eseguita il 30 aprile 2025, mentre la segnalazione del ricercatore indipendente è arrivata soltanto il 17 ottobre 2026.

Le chiavi utilizzavano la crittografia a curva ellittica ECC P-384, uno schema normalmente in grado di offrire un livello di sicurezza elevato. Il problema, però, non riguardava l’algoritmo, ma il valore effettivo delle chiavi private.

In una configurazione corretta, una chiave privata P-384 corrisponde a un intero selezionato casualmente all’interno di uno spazio estremamente ampio, determinato dall’ordine del punto generatore sulla curva. La chiave pubblica deriva dalla moltiplicazione scalare di tale punto per l’intero segreto.

Ricostruire la chiave privata conoscendo soltanto quella pubblica richiederebbe, in condizioni normali, la soluzione del problema del logaritmo discreto su curve ellittiche, considerato computazionalmente impraticabile con le tecnologie convenzionali disponibili.

Le 8 chiavi eMudhra, però, presentavano valori privati inferiori a 256: anziché cercare un segreto in uno spazio crittografico enorme, un attaccante avrebbe potuto verificare un numero estremamente limitato di candidati, calcolandone le corrispondenti chiavi pubbliche e confrontandole con quelle contenute nei certificati.

In altre parole, non serviva violare P-384: bastava individuare quale dei pochissimi valori possibili producesse la chiave pubblica conosciuta: un’operazione praticamente immediata.

Certificati HTTPS falsi e software apparentemente attendibili: quali rischi

Una CA intermedia possiede il potere di emettere certificati destinati a soggetti terzi: se un attaccante recupera la chiave privata corrispondente, può utilizzare quell’identità crittografica per firmare certificati fraudolenti.

Nel caso dei certificati TLS, lo scenario più preoccupante riguarda proprio la creazione di certificati per domini che l’attaccante non controlla: se un browser continua a fidarsi della gerarchia interessata e l’aggressore riesce a intercettare o deviare una connessione, può tentare un attacco man-in-the-middle (MitM).

Immaginiamo un utente che apre il sito della propria banca attraverso una rete compromessa. Un aggressore in grado di presentare un certificato fraudolento, ma apparentemente valido, potrebbe convincere il browser di trovarsi davanti al server autentico. In determinate condizioni diventerebbe possibile intercettare credenziali, sessioni e informazioni trasmesse dall’utente.

Windows, Edge e WebView2: Microsoft applica tre livelli di protezione

Microsoft ha reagito utilizzando meccanismi differenti, ciascuno con una funzione precisa. Il 20 ottobre ha aggiornato la Disallowed Certificate Trust List (CTL) di Windows, inserendo tra i certificati non attendibili quelli delle autorità intermedie coinvolte.

Parallelamente, Microsoft ha distribuito un aggiornamento dei CRLSet per Edge e WebView2, così da bloccare i certificati TLS collegati alle CA interessate. CRLSet è un meccanismo utilizzato dai browser basati su Chromium per distribuire rapidamente informazioni relative a certificati da rifiutare.

La distribuzione avviene attraverso gli aggiornamenti dei componenti del browser: non richiede necessariamente il download di una nuova versione completa di Edge. Anche le applicazioni che integrano WebView2 possono beneficiare della protezione, purché ricevano gli aggiornamenti previsti per il relativo runtime.

La terza misura, annunciata il 26 ottobre, interessa direttamente le root of trust, ossia le autorità di certificazione radice che rappresentano il punto di partenza delle catene di fiducia utilizzate per verificare l’autenticità dei certificati digitali.

Eliminando i 7 certificati dalle liste attendibili, Microsoft riduce la possibilità che altri certificati appartenenti alle gerarchie coinvolte continuino a ottenere una validazione positiva.

Cosa devono controllare gli amministratori Windows

Per gli utenti che utilizzano Windows 11 con gli aggiornamenti automatici e la normale connettività Internet, Microsoft non richiede una procedura manuale specifica: è necessario consentire la distribuzione degli aggiornamenti delle liste dei certificati e dei componenti Edge.

La situazione cambia per i computer isolati dalla rete, i server aziendali con configurazioni restrittive e gli ambienti nei quali gli aggiornamenti delle radici attendibili sono disabilitati.

Microsoft raccomanda di verificare che anche queste installazioni ricevano le versioni aggiornate delle CTL. La documentazione tecnica Microsoft illustra come distribuire le liste attraverso server interni e criteri di gruppo, senza concedere necessariamente a tutti i dispositivi l’accesso diretto a Windows Update.

Un amministratore può inoltre utilizzare certmgr.msc per esaminare i certificati dell’utente e certlm.msc per quelli del computer locale. Si tratta però di strumenti di ispezione: la presenza o l’assenza di un certificato in una determinata cartella non dimostra, da sola, quale decisione assumerà Windows durante la validazione di una specifica catena.

Windows 11: Microsoft rilascia tre aggiornamenti straordinari per i certificati

Per assicurare la distribuzione delle nuove informazioni sulla fiducia dei certificati anche ai sistemi che non ricevono gli aggiornamenti automatici delle CTL, Microsoft ha pubblicato tre aggiornamenti cumulativi out-of-band (OOB) per Windows 11, ciascuno destinato a versioni differenti del sistema operativo.

Il primo è KB5134133, che riguarda Windows 11 24H2, 25H2 e 26H2 e porta rispettivamente le build a 26100.9725, 26200.9725 e 26300.9725. Il secondo, KB5134134, interessa Windows 11 26H1 e aggiorna il sistema alla build 28000.3237. Infine, KB5134130 è destinato a Windows 11 23H2, con il passaggio alla build 22631.7654.

La particolarità di questi aggiornamenti è che Microsoft li classifica come interventi non di sicurezza, pur avendo una funzione direttamente collegata alla protezione della catena di fiducia. I pacchetti includono infatti un payload aggiornato dei certificati root attendibili, incorporato negli aggiornamenti cumulativi di Windows. Si tratta di una soluzione pensata soprattutto per i computer che non possono collegarsi ai servizi Microsoft dedicati all’aggiornamento dei certificati.

Microsoft rende disponibili i pacchetti anche attraverso il Microsoft Update Catalog, con possibilità di distribuzione anche mediante Windows Server Update Services (WSUS).

Nella documentazione di KB5134133 Microsoft segnala un problema noto che può impedire l’attivazione di Smart App Control sui dispositivi nei quali la funzione risulta disabilitata. I sistemi che la utilizzano già non subiscono conseguenze. Microsoft ha pubblicato una procedura correttiva tramite Registro di sistema o criteri di gruppo e sta preparando una soluzione definitiva.

eMudhra: nessuna evidenza di certificati finali emessi dalle CA coinvolte

Un elemento contribuisce a delimitare la portata effettiva dell’incidente. Secondo eMudhra, nessuna delle autorità intermedie compromesse aveva emesso certificati finali pubblicamente attendibili. Sette delle 8 CA non erano mai entrate in produzione e l’unica utilizzata non aveva rilasciato certificati.

La società afferma inoltre di non aver rilevato compromissioni dell’infrastruttura o sottrazioni di dati dei clienti. Le chiavi private delle autorità root non risultano coinvolte.

La precisazione non elimina il rischio teorico: chiunque fosse riuscito a ricostruire le chiavi degli intermedi avrebbe potuto tentare di utilizzarle autonomamente per creare certificati fraudolenti. Il fatto che eMudhra non abbia emesso certificati tramite quelle CA non equivale alla dimostrazione che nessun altro abbia sfruttato le chiavi vulnerabili.

Le conseguenze dell’incidente sono state comunque pesanti. Il 22 ottobre 2026, con un comunicato ufficiale, eMudhra ha annunciato la decisione del consiglio di amministrazione di abbandonare definitivamente il mercato globale dei certificati SSL/TLS. La società ha spiegato che tale attività rappresenta circa l’1% del fatturato complessivo e che i crescenti costi operativi, gli obblighi normativi e la pressione concorrenziale avevano già ridotto l’interesse economico del settore. L’incidente di sicurezza e le sue ripercussioni sulla reputazione hanno contribuito alla decisione.

L’uscita dal settore SSL/TLS avverrà gradualmente: le autorità radice RSA G1 continueranno a supportare i clienti durante la transizione, mentre eMudhra offrirà certificati sostitutivi gratuiti attraverso partner esterni.