Certificati eMudhra compromessi: aggiornare le CTL di Windows sui server non connessi

Articolo aggiornato al 30 ottobre 2026. La situazione è ancora in evoluzione: lo aggiornerò se Microsoft rilascia nuove correzioni.

Avete server Windows che non escono su Internet, o PC in reparti isolati dietro un firewall che lascia passare solo il minimo indispensabile? Su quelle macchine, in questi giorni, potrebbe mancare un aggiornamento importante che non passa dal normale Patch Tuesday: quello dell’elenco dei certificati di cui Windows si fida.

Il motivo è la compromissione dell’autorità di certificazione indiana eMudhra. Secondo il Microsoft Security Response Center sono risultate recuperabili le chiavi private di otto CA intermedie della sua gerarchia, sei per i certificati TLS e due per la firma del codice. Chi le possiede può emettere certificati per siti o firmare software che a Windows sembrano legittimi. Il 20 ottobre Microsoft ha aggiunto le CA coinvolte all’elenco dei certificati non attendibili (Disallowed CTL) e il 26 ottobre ha rilasciato aggiornamenti fuori ciclo che rimuovono dall’elenco delle radici attendibili sei radici eMudhra G3 e un certificato incrociato collegato. Sui computer collegati tutto questo arriva da solo; su quelli isolati no.

Chi è coinvolto

Windows scarica gli elenchi dei certificati (le CTL, Certificate Trust List) in automatico da ctldl.windowsupdate.com, indipendentemente da WSUS. Dovete preoccuparvi solo se rientrate in uno di questi casi:

server o PC senza accesso a Internet, o con un firewall che blocca ctldl.windowsupdate.com sulla porta 80;
macchine su cui qualcuno ha disattivato l’aggiornamento automatico dei certificati radice, spesso con un criterio di gruppo dimenticato da anni;
organizzazioni che usano certificati emessi da eMudhra: in Italia sono rari, ma vale la pena controllare.

Edge e WebView2 hanno ricevuto un blocco separato tramite gli aggiornamenti dei componenti, senza bisogno di una nuova versione del browser.

Prima di iniziare: verificate se le CTL arrivano

Da un prompt dei comandi come amministratore, controllate la data dell’ultima sincronizzazione dei due elenchi:

certutil -verifyctl AuthRoot | findstr /i "lastsynctime"
certutil -verifyctl Disallowed | findstr /i "lastsynctime"

Se le date sono di oggi o di ieri, la macchina si aggiorna da sola e non dovete fare altro. Se sono vecchie di settimane o mesi, verificate la raggiungibilità del server Microsoft e la presenza di criteri che bloccano l’aggiornamento:

Test-NetConnection ctldl.windowsupdate.com -Port 80
reg query "HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot"

Il valore DisableRootAutoUpdate impostato a 1 significa che l’aggiornamento delle radici è disattivato; EnableDisallowedCertAutoUpdate a 0 blocca quello dei certificati non attendibili. Di solito li imposta il criterio “Turn off Automatic Root Certificates Update”, che trovate in Configurazione computer → Modelli amministrativi → Sistema → Gestione comunicazioni Internet → Impostazioni comunicazioni Internet. Se nessuno sa più perché è stato attivato, io lo riporterei a “Non configurato”.

Soluzione 1: gli aggiornamenti fuori ciclo

Gli aggiornamenti del 26 ottobre sono cumulativi, non di sicurezza, e si scaricano solo dal Microsoft Update Catalog: chi è collegato non li vede in Windows Update e non ne ha bisogno. Quelli per le versioni più diffuse nelle PMI sono:

Windows Server 2025: KB5134137
Windows Server 2022: KB5134140
Windows Server 2019 e Windows 10 1809: KB5134124
Windows Server 2016 e Windows 10 1607: KB5134123
Windows 10 21H2 e 22H2: KB5134125
Windows 11 24H2, 25H2 e 26H2: KB5134133; 23H2: KB5134130

Attenzione: questi pacchetti includono tutto l’aggiornamento di sicurezza del 13 ottobre, compresi i suoi problemi noti. Sui server Exchange in sede vale il discorso del limite sulle chiamate all’Endpoint Mapper, di cui ho parlato in Exchange non risponde dopo gli update di ottobre. Prima di installare, snapshot della VM o backup recente, come sempre.

Soluzione 2: distribuire le CTL dalla rete interna

È quella che preferisco, perché non risolve solo questo episodio: da qui in avanti le macchine isolate ricevono ogni modifica agli elenchi senza aspettare un aggiornamento fuori ciclo. Serve un solo server che esce su Internet e una cartella condivisa leggibile dagli altri.

Sul server collegato, scaricate i file delle CTL nella condivisione:

certutil -syncWithWU \\SRV01\CTL

Verificate che nella cartella ci siano authrootstl.cab e disallowedcertstl.cab, e create un’attività pianificata che ripeta il comando ogni giorno.
Sulle macchine isolate indicate la nuova origine. Per una prova su un singolo server:

reg add "HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate" /v RootDirURL /t REG_SZ /d "file://\\SRV01\CTL" /f

Quando funziona, distribuite l’impostazione con un criterio di gruppo invece che a mano, e rilanciate i due comandi certutil -verifyctl per controllare che la data di sincronizzazione sia cambiata.

Attenzione: le impostazioni di registro scritte da questi criteri non spariscono se scollegate o eliminate il GPO. Annotatevi cosa avete cambiato, per poterlo riportare indietro.

Controllate i vostri certificati

Se un vostro servizio usa un certificato che dipende dalle radici rimosse, smetterà di essere considerato valido man mano che l’aggiornamento arriva ai client. Su ogni server potete fare un primo controllo così:

Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Issuer -like '*eMudhra*' } |
    Select-Object Subject, Issuer, NotAfter, Thumbprint

Se trovate qualcosa, chiedete un nuovo certificato a un’altra CA prima che i client lo rifiutino. Microsoft sconsiglia di ripristinare a mano la fiducia nella gerarchia eMudhra, e lo sconsiglio anch’io: significherebbe annullare proprio la protezione che serve. Non provate nemmeno a togliere a mano certificati dall’archivio delle radici basandovi sul nome: il certificato incrociato rimosso porta il nome di una radice molto diffusa, e cancellare quella sbagliata vi farebbe solo danni.

Se il problema persiste

Se dopo la sincronizzazione un’applicazione segnala errori di catena o “certificato non attendibile”, guardate nel Visualizzatore eventi, sotto Registri applicazioni e servizi → Microsoft → Windows → CAPI2, dopo aver attivato il registro Operativo. Ricordate poi che Windows non è l’unico archivio: Java, Python, molte appliance Linux e i container hanno il proprio elenco di radici e vanno aggiornati con i loro canali. Microsoft sta ancora valutando le altre radici eMudhra, quindi è probabile che arrivino altre modifiche: un motivo in più per far arrivare le CTL ovunque in modo automatico.

Vi è capitato di scoprire criteri che bloccavano l’aggiornamento dei certificati radice su server di cui nessuno ricordava la configurazione? Raccontate nei commenti come avete distribuito le CTL nelle reti isolate: possono essere utili ad altri.