Windows Update derrière proxy ou pare-feu : revoir les exceptions TLS avant les prochains déploiements
Microsoft remet en avant les contraintes réseau de Windows Update. L'inspection TLS ou une allowlist trop approximative peut casser les scans.
- Impact
- Scans, téléchargements et anneaux
- Action
- Auditer les chemins clients
- Statut
- À planifier
Ce n’est pas une rupture de service annoncée, mais un rappel utile pour les équipes qui verrouillent les sorties Internet, généralisent les VPN permanents ou préparent de nouveaux anneaux Windows 11. Un anneau Windows Update for Business propre côté Intune peut échouer si le chemin réseau intercepte ou filtre mal Windows Update.
Ce qui change
Fait sourcé : le Windows Message Center a publié le 31 août 2026 à 10:00 PT un rappel intitulé Reminder: Configure firewall and proxies for smooth Windows updates. Le message renvoie vers un guide Microsoft qui demande de faire confiance aux sous-domaines FQDN recommandés plutôt que de raisonner en plages IP.
Le mécanisme n’est pas nouveau. Microsoft documente que les échanges de métadonnées Windows Update utilisent HTTPS et que ces connexions sont protégées par certificate pinning. Si un proxy TLS remplace le certificat serveur par un certificat interne, le client Windows Update peut refuser la connexion.
Qui est concerné
Sont concernés les environnements qui laissent les postes Windows 10 ou Windows 11 joindre Windows Update, Microsoft Update, Microsoft Store, Delivery Optimization ou Windows Update for Business à travers un proxy, un filtrage DNS, un pare-feu applicatif, un VPN d’entreprise ou une inspection TLS.
Le sujet touche aussi les organisations hybrides MECM/Configuration Manager. Quand les clients scannent contre un WSUS interne via un software update point, le chemin client vers Windows Update est moins direct. En revanche, les synchronisations amont, les clients Internet, les workloads co-gérés et le durcissement TLS/SSL du SUP restent à vérifier séparément.
Impact opérationnel
Fait sourcé : Windows Update ne se limite pas au téléchargement de fichiers. Le client échange d’abord des métadonnées en HTTPS, puis télécharge les contenus via Delivery Optimization, HTTP ou pair-à-pair selon la configuration. Les binaires sont ensuite validés par signature numérique et hash avant installation.
Les symptômes peuvent être trompeurs. Un test navigateur vers une URL Microsoft ne prouve pas que le protocole Windows Update fonctionne de bout en bout, car ces endpoints ne sont pas conçus comme des pages web utilisateur. DNS bloqué, endpoint inaccessible, proxy restrictif ou inspection TLS peuvent produire des postes bloqués en scan, des anneaux décalés et des mises à jour Defender ou pilotes en retard.
Actions recommandées
- Inventorier les chemins réseau réellement utilisés par les postes : LAN siège, agences, Wi-Fi de staging, VPN utilisateur, VPN always-on, réseau OOBE, accès Internet direct et clients hors réseau.
- Vérifier que les flux Windows Update passent sans inspection TLS quand Microsoft l’exige, en particulier pour les échanges de métadonnées.
- Mettre à jour les règles proxy et pare-feu avec les FQDN documentés, notamment les familles
*.update.microsoft.com,*.delivery.mp.microsoft.com,*.dl.delivery.mp.microsoft.comet*.prod.do.dsp.mp.microsoft.comlorsque le périmètre les utilise. - Créer un test de santé par segment réseau : génération de
WindowsUpdate.log, scan contrôlé, relevé des codes d’erreur, validation DNS/FQDN et contrôle de l’absence d’interception TLS. - Pour MECM, ajouter une vérification distincte du SUP/WSUS en HTTPS quand cette option est utilisée, y compris le magasin de certificats
WindowsServerUpdateServicessi le certificate pinning WSUS est activé.
Échéances et points de vigilance
Les sources consultées ne donnent pas d’échéance de rupture unique. Le rappel Message Center du 31 août 2026 remet en avant une dépendance permanente de sécurité et de fonctionnement.
Ne transformez pas l’allowlist en ouverture IP approximative. Microsoft indique ne pas fournir de plages IP stables pour ces exceptions, car les adresses peuvent varier avec l’équilibrage et l’évolution du service. Le bon niveau de contrôle est le FQDN documenté, testé depuis le client Windows Update lui-même.
Sources
- Microsoft Learn — Windows Message Center, rappel du 31 août 2026
- Microsoft Tech Community — Configuring firewall and proxies for smooth Windows updates
- Microsoft Learn — Windows Update security
- Microsoft Learn — Connection endpoints for Windows 11 Enterprise
- Microsoft Learn — Configure a software update point to use TLS/SSL with a PKI certificate