Spåra proxyfel i CRL- och OCSP-certifikatkontroller
Spåra CRL- eller OCSP-hämtning under verifierarens konto när programmet når sin proxy men certifikatvalideringen inte kan slutföras.
En webbplatsbegäran kan nå sin proxy och ändå misslyckas eftersom certifikatverifieringen behöver ännu en nätverksbegäran. En CRL- eller OCSP-hämtning kan gå via en plattformskomponent med ett annat konto och en annan proxyprincip än programmets HTTP-klient.
Börja med det exakta kedjefelet. Revoked betyder något annat än kan inte hämta aktuell återkallningsinformation. Utgång och en icke betrodd utfärdare är återigen andra problem. Bara hämtningsfelet kräver spårning av en saknad väg till en status-URL.
För det felet, identifiera tre saker tillsammans: URL:en som hämtas, komponenten som utför hämtningen och dess processidentitet. Att en webbläsare öppnar URL:en med ditt interaktiva konto bevisar inte att en tjänst kan autentisera sig mot samma proxy.
Om den identifierade komponenten använder WinHTTP, granska principen som gäller för den. Statisk proxykonfiguration och automatisk proxyutvärdering per URL är separata mekanismer. Använd den stödda konfigurationen för det avsedda kontot; att kopiera webbläsarinställningar eller ändra en orelaterad körmiljö kan lämna den faktiska hämtningen orörd.
I .NET styr UrlRetrievalTimeout i kedjeprincipen en väntan på onlineverifiering eller CRL-hämtning. Att förlänga den vanliga HTTP-svarstiden förlänger inte samma timer, och att förlänga hämtningstimern ger inte proxyautentiseringsuppgifter eller en väg.
En HTTPS-proxy kan göra detta beroende synligt redan före TLS mot målet: förtroendet för proxyanslutningen kan i sig kräva återkallningshämtning. Återställ den stödda hämtningsåtkomsten och förtroendeordningen i det skedet. Att stänga av återkallningskontrollen ändrar certifikatprincipen; det återställer inte den misslyckade hämtningen.