Windows et Edge : déployer les protections eMudhra, avec une attention aux postes sans CTL
Microsoft confirme le retrait des sept certificats concernés de la liste de confiance Edge le 27 octobre ; des mises à jour Windows hors bande du 26 couvrent les appareils privés de mises à jour CTL. Contrôler les deux circuits de distribution et cibler ces paquets Windows sur le périmètre concerné, en tenant compte de leur effet sur Hotpatch.
- Impact
- confiance des certificats sous Windows, Edge et WebView2 ; besoin particulier pour les postes déconnectés ou dont les mises à jour CTL sont désactivées.
- Action
- vérifier la réception des protections, déployer la mise à jour Windows appropriée si les CTL ne parviennent pas au poste, puis retester les services dépendants.
- Statut
- À déployer
Ce qui est désormais confirmé
Dans son billet du 26 octobre, actualisé le 27, Microsoft décrit huit clés d’autorités intermédiaires eMudhra compromises : six TLS et deux de signature de code. L’incident ne concerne pas une compromission des systèmes Microsoft.
Les protections restent distinctes :
- 20 octobre : blocage des clés concernées dans la liste Windows Disallowed et diffusion d’un CRLSet pour Edge/WebView2. Ce dernier arrive par mise à jour de composants, sans nouvelle version du navigateur nécessaire.
- 26 octobre : retrait de six racines eMudhra G3 et d’un certificat croisé AAA Certificate Services de la liste de confiance Windows.
- 27 octobre : retrait également effectué côté Edge. Le Trusted Root Program identifie le composant PKI Metadata 72.0.0.0 pour cette opération Edge/WebView2.
Le retrait côté éditeur ne prouve pas la réception sur chaque poste. La révocation des intermédiaires par les autorités, leur blocage par Microsoft et le retrait des racines ne sont pas interchangeables. L’enquête continue.
Windows : choisir le circuit adapté
Les appareils recevant les CTL Microsoft obtiennent le contenu de confiance actualisé par ce circuit. Les mises à jour OOB ci-dessous visent les appareils qui ne reçoivent pas les CTL courantes, notamment hors réseau ou sans accès au service de certificats Microsoft. Ce sont des cumulatives classées non-sécurité par Microsoft, malgré leur rôle dans la réponse à cet incident.
| Windows 11 | Mise à jour du 26 octobre | Build après installation |
|---|---|---|
| 24H2 / 25H2 / 26H2 | KB5134133 | 26100.9725 / 26200.9725 / 26300.9725 |
| 26H1 | KB5134134 | 28000.3237 |
| 23H2 | KB5134130 | 22631.7654 |
Table limitée à Windows 11, pour les éditions encore prises en charge ; ne pas transposer ces KB à Windows 10 ou Windows Server.
Les trois pages indiquent une disponibilité dans Microsoft Update Catalog : ne pas supposer une arrivée automatique dans vos anneaux. Pour 24H2/25H2, KB5134133 demande une cumulative du 10 juin 2025 ou ultérieure ; pour 23H2, KB5134130 demande celle du 8 juillet 2025 ou ultérieure. Respecter également les prérequis SSU de chaque KB.
Attention Hotpatch : la note ajoutée à KB5134133 le 27 octobre précise que les appareils inscrits à Hotpatch qui installent ce paquet ne recevront plus de hotpatches avant d’avoir installé la baseline de janvier 2027. Prévoir leur maintenance par mises à jour classiques entre-temps ; cette recommandation ne constitue pas une nouvelle échéance Microsoft.
KB5134133 conserve des problèmes connus : activation de Smart App Control, RDP non-administrateur avec Administrator protection et certains périphériques USB Audio Class 1.0. Cette OOB ne doit pas être présentée comme leur correction.
Contrôler le résultat et les usages
Sur un segment Windows déconnecté, vérifier la synchronisation et l’accès au dépôt CTL interne, notamment pour authrootstl.cab et disallowedcertstl.cab. La procédure de redirection Microsoft vise des clients membres d’un domaine AD DS et reste indépendante de WSUS. Si la voie OOB est retenue, comparer le résultat d’installation et la build effectivement démarrée à la table, après le redémarrage demandé. Un échec impose de corriger les prérequis ou la distribution avant élargissement. Le paquet ne remplace pas l’entretien durable du circuit CTL.
Dans Edge, ouvrir edge://components sur un poste représentatif et contrôler CRLSet selon la procédure du Trusted Root Program. Si le composant n’est pas actualisé, utiliser Check for update, puis diagnostiquer les échecs réseau persistants. Distinguer ce blocage des clés TLS du retrait des racines par PKI Metadata. Le seul numéro d’Edge ne suffit pas ; une stratégie ComponentUpdatesEnabled désactivée ne prouve pas non plus le blocage de CRLSet, les listes de révocation étant exemptées.
Avec les responsables PKI et applicatifs, comparer les chaînes utilisées aux empreintes des sept certificats publiées par Microsoft. Remplacer les certificats dépendants ou adopter une autre chaîne approuvée, puis comparer les accès TLS et validations de signature avant/après sur les applications concernées. Élargir lorsque les protections sont reçues et les usages attendus fonctionnent ; sinon conserver les erreurs et chaînes pour diagnostic. Ne pas rétablir la confiance localement par défaut : Microsoft souligne le risque des logiciels qui ne vérifient pas correctement révocation et liste Disallowed.
Ces contrôles sont des recommandations ; aucun test de poste ou de certificat n’a été exécuté pour cette analyse.
Sources
- MSRC : incident et confirmation du retrait Edge le 27 octobre.
- Trusted Root Program : composants, contrôles et empreintes.
- KB5134133 : 24H2/25H2/26H2 et restriction Hotpatch.
- KB5134134 : Windows 11 26H1.
- KB5134130 : Windows 11 23H2.
- Windows : distribution des CTL en environnement déconnecté.
- Edge : exceptions de ComponentUpdatesEnabled.