Sporing af proxyfejl i CRL- og OCSP-certifikatkontroller
Spor CRL- eller OCSP-hentning under verificeringskontoen, når programmet når sin proxy, men certifikatvalideringen ikke kan fuldføres.
En anmodning til et websted kan nå sin proxy og alligevel fejle, fordi certifikatverifikation kræver endnu en netværksanmodning. En CRL- eller OCSP-hentning kan køre gennem en platformskomponent med en anden konto og proxy-politik end programmets HTTP-klient.
Start med den præcise kædefejl. Tilbagekaldt betyder noget andet end kan ikke hente aktuelle tilbagekaldelsesoplysninger. Udløb og en ikke-betroet udsteder er igen andre problemer. Kun hentningsfejlen kræver sporing af en manglende rute til en status-URL.
For den fejl skal du identificere tre ting sammen: den URL, der hentes, den komponent, der udfører hentningen, og dens procesidentitet. At en browser åbner URL'en med succes under din interaktive konto beviser ikke, at en tjeneste kan godkende sig over for den samme proxy.
Hvis den identificerede komponent bruger WinHTTP, skal du undersøge den politik, der gælder for den. Statisk proxykonfiguration og automatisk proxyvurdering pr. URL er separate mekanismer. Anvend den understøttede konfiguration for den tilsigtede konto; kopiering af browserindstillinger eller ændring af et urelateret runtime kan lade den faktiske hentning være urørt.
I .NET styrer UrlRetrievalTimeout på kædepolitikken en ventetid på onlineverifikation eller CRL-hentning. Forlængelse af den almindelige HTTP-svartimeout forlænger ikke den samme timer, og forlængelse af hentetimeren giver ikke proxy-legitimationsoplysninger eller en rute.
En HTTPS-proxy kan gøre denne afhængighed synlig endda før destinationens TLS: tillid til proxyforbindelsen kan i sig selv kræve hentning af tilbagekaldelsesoplysninger. Gendan den understøttede hentningsadgang og tillidsordning på det tidspunkt. Deaktivering af tilbagekaldelseskontrol ændrer certifikatpolitikken; det gendanner ikke den mislykkede hentning.