← Toutes les publications

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.com et *.prod.do.dsp.mp.microsoft.com lorsque 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 WindowsServerUpdateServices si 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