Visual Studio lent uniquement sur VPN ? Vérifiez CRL et OCSP

Visual Studio démarre normalement à la maison, puis le même portable rejoint le tunnel d’entreprise et chaque lancement reste une demi-minute sur l’écran de démarrage. Retirez la stratégie et le blocage disparaît avec elle ; retirez le tunnel et la même chose se produit. Les deux observations sont exactes, c’est pourquoi les deux composants s’accusent mutuellement. La question décisive est de savoir si une vérification de révocation de certificat attend un chemin que seul le tunnel fournit, ou si elle n’en trouve aucun.

Mesurez la récupération, pas le lancement

Une stratégie WDAC, déployée sous forme de fichier SiPolicy.p7b signé, décide quelles images peuvent s’exécuter sur la machine. L’intégrité du code valide la chaîne de signatures d’une image avant son exécution, et cette validation peut inclure une question de révocation. La réponse dépend du point de distribution CRL ou du répondeur OCSP que le certificat nomme en son sein.

Ce sont des requêtes réseau ordinaires, donc leur coût dépend de l’emplacement du répondeur. Quand il n’est joignable que par le tunnel, ou que son nom ne se résout que par un serveur DNS derrière le tunnel, la validation attend que le tunnel soit prêt. Visual Studio charge au démarrage un grand nombre d’assemblages et d’extensions signés, et un petit retard par image devient un blocage visible. Rien n’est mal formé et la stratégie se comporte exactement comme configurée, c’est pourquoi retirer la stratégie semble corriger le problème.

Chaque image signée peut déclencher un appel réseau

Partez d’un binaire signé déjà présent sur le disque et demandez à la plateforme de le vérifier avec le même comportement de récupération qu’un lancement. Exécutez la commande une fois sur le tunnel et une fois en dehors, puis comparez les lignes de récupération plutôt que le verdict final.

certutil -verify -urlfetch C:\Tools\Contoso.Editor.dll
nslookup ocsp.contoso.example
Test-NetConnection ocsp.contoso.example -Port 80

La sortie énumère la chaîne, les adresses CRL et OCSP et si chaque récupération a réussi. Un répondeur qui expire sur le tunnel et répond en dehors est la preuve qu’il vous faut, et elle pèse bien plus qu’une impression de lenteur. Si la récupération réussit lentement, notez l’adresse pour que l’étape suivante puisse tester cet hôte directement.

Résolvez le nom d’hôte du répondeur et testez l’accessibilité en dehors de l’application, car un nom qui ne se résout pas ne sera jamais réparé par un réglage client. Le journal opérationnel CodeIntegrity fournit l’autre moitié de la preuve, en reliant un événement de validation à l’horodatage du lancement lent.

Réduisez le délai sans retirer le contrôle

Désactiver la stratégie ou la passer en mode audit fait disparaître le délai et retire le contrôle déployé par l’organisation, alors considérez cela comme la mauvaise réparation. Les options plus étroites sont un changement de routage pour que le répondeur soit joignable par le tunnel, une exclusion dans le tunneling divisé pour les hôtes du répondeur, une correction DNS quand le nom se résout vers une adresse injoignable, ou un proxy de cache pris en charge pour les données de révocation. Chacune a un propriétaire différent : l’équipe PKI possède l’accessibilité du répondeur, l’équipe réseau possède la division du tunnel et l’équipe poste de travail possède la stratégie.

Exclure chaque hôte de révocation du tunnel n’est pas automatiquement sûr, car un répondeur interne peut être interne à dessein. Confirmez l’exclusion avec l’équipe qui exploite la PKI avant d’écrire une règle qui envoie discrètement les vérifications de certificats vers l’internet public. Un changement fait sans cette confirmation est du genre à être annulé au prochain rafraîchissement de la stratégie.

Vérifiez un démarrage à froid après le changement

Mesurez un démarrage à froid dans les deux états et conservez les chiffres, car un démarrage à chaud ne prouve presque rien une fois les assemblages en cache. Répétez le lancement depuis une session neuve pour que le chemin de chargement des extensions soit de nouveau sollicité.

Get-WinEvent -LogName Microsoft-Windows-CodeIntegrity/Operational -MaxEvents 40 |
  Where-Object { $_.TimeCreated -gt (Get-Date).AddMinutes(-10) }
Get-ChildItem C:\Windows\System32\CodeIntegrity\CiPolicies\Active
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

Une configuration réparée contacte toujours le répondeur, ou utilise un chemin de cache approuvé par votre équipe PKI, et le journal montre la validation se terminer plutôt que d’expirer. Confirmez qu’une application récemment signée démarre toujours, car une stratégie qui autorise tout n’est pas une réparation réussie. Vérifiez aussi le dossier de stratégie active et l’état d’application, afin que la stratégie que vous déboguez soit bien celle qui s’exécute. Gardez la chaîne de certificats, l’adresse du répondeur et les horodatages de lancement dans le même ticket, car un renouvellement déplace généralement le répondeur et laisse la règle d’exclusion ou DNS obsolète.