Windows Update bloccato in azienda: bypass Microsoft per firewall, proxy e TLS inspection

Quando Windows Update smette improvvisamente di scaricare gli aggiornamenti, il primo sospetto cade spesso sul sistema operativo: componenti danneggiati, cache degli aggiornamenti corrotta, servizi bloccati oppure qualche problema introdotto da una patch precedente. In un altro articolo abbiamo proprio visto come effettuare il reset di Windows Update.

In reti aziendali e ambienti gestiti, tuttavia, la causa può trovarsi completamente fuori dal PC. Firewall, proxy, VPN e sistemi di ispezione HTTPS possono infatti impedire a Windows Update di raggiungere correttamente l’infrastruttura Microsoft oppure alterare la connessione TLS utilizzata per verificare l’identità dei server.

Microsoft è tornata sull’argomento spiegando che, in diversi casi, la correzione consiste in qualcosa di apparentemente semplice: configurare firewall e proxy affinché lascino transitare alcune connessioni Windows Update senza sottoporle a TLS inspection.

L’errore 0x80240438 fornisce un indizio molto importante

Uno degli errori richiamati da Microsoft è 0x80240438, identificato come WU_E_NETWORK_ERROR. Non indica necessariamente un componente Windows Update danneggiato; può significare semplicemente che il client non riesce a completare la comunicazione con uno dei server necessari. Microsoft associa gli errori di questa famiglia a problemi di rete, DNS, proxy o firewall.

Un nome come download.windowsupdate.com può essere correttamente risolto dal DNS, mentre il traffico successivo viene bloccato dal firewall aziendale. È uno dei motivi per cui limitarsi a un nslookup non è sufficiente.

Ancora più interessante è il caso nel quale il firewall o il proxy non blocca realmente la connessione, ma la intercetta: numerose appliance di sicurezza aziendali utilizzano una tecnica chiamata TLS inspection, SSL inspection o HTTPS inspection.

Invece di lasciare che il computer stabilisca direttamente una connessione TLS con Microsoft, l’appliance termina la sessione HTTPS, analizza il traffico e crea una seconda connessione verso Internet.

Microsoft spiega esplicitamente che i collegamenti destinati a Windows Update devono poter attraversare firewall e proxy senza che questi generino e sostituiscano il certificato TLS atteso dal client. Tra i codici citati in relazione a queste condizioni compaiono errori come 0x80245006 e 0x80240437, che possono manifestarsi durante la validazione delle comunicazioni con i servizi Windows Update.

Il “bypass” consigliato da Microsoft

Per risolvere i malfunzionamenti con Windows Update, soprattutto in ambito aziendale, Microsoft cita un bypass che riguarda proxy e firewall: le connessioni destinate agli endpoint Windows Update devono essere escluse dalle operazioni di decrittazione e re-ispezione HTTPS.

Microsoft suggerisce di creare delle regole di pass-through, allowlist o SSL inspection bypass basate sugli FQDN (Fully Qualified Domain Name) richiesti. Uno degli esempi più intuitivi è il seguente (l’asterisco permette di comprendere i vari host utilizzati sotto quel dominio):

*.update.microsoft.com

Quali endpoint Windows Update devono attraversare firewall e proxy

È fondamentale non limitarsi al solo *.update.microsoft.com: Windows Update utilizza più domini per ricerca, metadati, download e Delivery Optimization. Microsoft indica, tra gli altri:

*.prod.do.dsp.mp.microsoft.com
*.dl.delivery.mp.microsoft.com
*.windowsupdate.com
*.delivery.mp.microsoft.com
*.update.microsoft.com
tsfe.trafficshaping.dsp.mp.microsoft.com
*.api.cdp.microsoft.com

La soluzione pratica consiste quindi nel creare sul firewall o sul proxy delle regole basate sugli FQDN, evitando liste statiche di indirizzi IP. L’infrastruttura Microsoft è distribuita e gli indirizzi associati agli host possono cambiare.

C’è inoltre una precisazione importante: non tutti gli endpoint richiedono necessariamente lo stesso trattamento. Per Delivery Optimization, Microsoft documenta esplicitamente l’uso del certificate pinning su alcuni server e impone di escludere dalla TLS inspection endpoint come:

geo.prod.do.dsp.mp.microsoft.com
array*.prod.do.dsp.mp.microsoft.com

Nota finale

La regola generale resta quindi semplice: prima di resettare il servizio, bisogna verificare che Windows riesca davvero a parlare con Windows Update.

Se il DNS funziona ma la connessione fallisce, è importante controllare firewall e proxy; se TCP funziona ma compaiono errori di verifica del server, si controlla la TLS inspection; solo quando la rete è stata esclusa dalle possibili cause ha senso concentrarsi sullo stato del client.