Visual Studio långsamt bara på VPN? Kontrollera CRL och OCSP

Visual Studio startar normalt hemma, sedan ansluter samma laptop till företagstunneln och varje start står en halv minut på startskärmen. Ta bort principen och fördröjningen försvinner med den; ta bort tunneln och samma sak händer. Båda observationerna är korrekta, därför får de två komponenterna ständigt skulden för varandra. Den avgörande frågan är om en spärrförfrågan för ett certifikat väntar på en väg som bara tunneln erbjuder, eller inte hittar någon alls.

Mät hämtningen, inte starten

En WDAC-princip, distribuerad som en signerad SiPolicy.p7b, avgör vilka avbildningar som får köras på datorn. Kodintegritet validerar signaturkedjan för en avbildning före körning, och den valideringen kan innehålla en fråga om spärrning. Svaret beror på CRL-distributionspunkten eller OCSP-svararen som certifikatet namnger inuti sig.

Det är vanliga nätverksförfrågningar, så kostnaden beror på var svararen finns. När den bara nås genom tunneln, eller dess namn bara löses via en DNS-server bakom tunneln, väntar valideringen tills tunneln är klar. Visual Studio laddar vid start ett stort antal signerade sammansättningar och tillägg, och en liten fördröjning per avbildning blir ett synligt stopp. Ingenting är fel och principen beter sig exakt som konfigurerad, därför verkar det som att ta bort principen löser problemet.

Varje signerad avbildning kan utlösa ett nätverksanrop

Börja med en signerad binärfil som redan ligger på disken och be plattformen verifiera den med samma hämtningsbeteende som en start använder. Kör kommandot en gång på tunneln och en gång utanför den, jämför sedan hämtningsraderna i stället för den slutliga domen.

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

Utdata listar kedjan, CRL- och OCSP-adresserna och om varje hämtning lyckades. En svarare som får tidsgräns på tunneln och svarar utanför den är beviset du behöver, och det väger långt tyngre än ett intryck av långsamhet. Om hämtningen lyckas långsamt, notera adressen så att nästa steg kan testa den värden direkt.

Lös upp svararens värdnamn och testa nåbarheten utanför programmet, eftersom ett namn som inte löses aldrig repareras av en klientinställning. CodeIntegritys driftlogg ger den andra halvan av beviset och kopplar en valideringshändelse till tidsstämpeln för den långsamma starten.

Korta fördröjningen utan att ta bort kontrollen

Att inaktivera principen eller växla den till granskningsläge tar bort fördröjningen och tar bort kontrollen som organisationen distribuerade, så betrakta det som den felaktiga reparationen. De snävare alternativen är en routingändring så att svararen nås genom tunneln, ett undantag i den delade tunneln för svararens värdar, en DNS-korrigering när namnet löses till en onåbar adress, eller en stödd cachelagrande proxy för spärrdata. Var och en har en annan ägare: PKI-teamet äger svararens nåbarhet, nätverksteamet äger tunneluppdelningen och endpointteamet äger principen.

Att utesluta varje spärrvärd från tunneln är inte automatiskt säkert, eftersom en intern svarare kan vara intern med avsikt. Bekräfta undantaget med teamet som driver PKI:n innan du skriver en regel som tyst skickar certifikatkontroller till det offentliga internet. En ändring gjord utan den bekräftelsen är den sort som rullas tillbaka vid nästa principuppdatering.

Verifiera en kallstart efter ändringen

Mät en kallstart i båda tillstånden och spara siffrorna, för en varmstart bevisar nästan ingenting när sammansättningarna ligger i cache. Upprepa starten från en ny session så att tilläggens laddningsväg används igen.

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

En reparerad konfiguration kontaktar fortfarande svararen, eller använder en cachelagringsväg som ditt PKI-team godkänt, och loggen visar att valideringen slutförs i stället för att nå tidsgränsen. Bekräfta att ett nyligen signerat program fortfarande startar, för en princip som tillåter allt är inte en lyckad reparation. Kontrollera också mappen för den aktiva principen och tillämpningsstatusen, så att det är känt att principen du felsöker är den som körs. Håll certifikatkedjan, svararens adress och starttidsstämplarna i samma ärende, för en förnyelse flyttar oftast svararen och lämnar undantags- eller DNS-regeln inaktuell.