Spoor proxyfoute op in CRL- en OCSP-sertifikaatkontroles

’n Webwerfversoek kan sy proxy bereik en steeds misluk omdat sertifikaatverifikasie nog ’n netwerkversoek benodig. ’n CRL- of OCSP-onttrekking kan deur ’n platformkomponent uitgevoer word met ’n ander rekening en proxibeleid as die toepassing se HTTP-kliënt.

Begin met die presiese kettingfout. Herroep beteken iets anders as nie in staat om huidige herroepingsinligting te verkry nie. Verval en ’n nie-vertroude uitreiker is weer ander probleme. Slegs die onttrekkingsfout vereis die naspeuring van ’n ontbrekende roete na ’n status-URL.

Vir daardie fout, identifiseer drie dinge saam: die URL wat onttrek word, die komponent wat die onttrekking doen en sy prosesidentiteit. ’n Blaaier wat die URL suksesvol onder jou interaktiewe rekening oopmaak, bewys nie dat ’n diens by dieselfde proxy kan verifieer nie.

As die geïdentifiseerde komponent WinHTTP gebruik, ondersoek die beleid wat daarop van toepassing is. Statiese proxykonfigurasie en per-URL outomatiese proxy-evaluering is afsonderlike meganismes. Pas die ondersteunde konfigurasie vir die beoogde rekening toe; die kopiëring van blaaierinstellings of die verandering van ’n onverwante looptyd kan die werklike onttrekking onaangeraak laat.

In .NET beheer UrlRetrievalTimeout op die kettingbeleid ’n wag vir aanlyn verifikasie of CRL-onttrekking. Die verlenging van die gewone HTTP-responsetimeout verleng nie dieselfde tydhouer nie, en die verlenging van die onttrekkingstydhouer verskaf nie proxybewyse of ’n roete nie.

’n HTTPS-proxy kan hierdie afhanklikheid sigbaar maak selfs voor bestemming-TLS: vertroue in die proxyverbinding kan self herroepingsonttrekking vereis. Herstel die ondersteunde onttrekkingstoegang en vertrouensreëling in daardie stadium. Die deaktivering van herroepingskontrole verander die sertifikaatbeleid; dit herstel nie die mislukte onttrekking nie.