Proxyflaters folgje by CRL- en OCSP-sertifikaatkontrôles
Folgje it opheljen fan CRL of OCSP ûnder it akkount fan 'e ferifiearder as de applikaasje har proxy berikt, mar sertifikaatfalidaasje net ôfmeitsje kin.
In oanfraach nei in webside kin syn proxy berikke en dochs mislearje, om't sertifikaatferifikaasje noch in netwurkoanfraach nedich hat. It opheljen fan CRL of OCSP kin ferrinne fia in platfoarmkomponint mei in oar akkount en proxybelied as de HTTP-klant fan 'e applikaasje.
Begjin mei de krekte keatlingflater. Ynlutsen betsjut eat oars as kin gjin aktuele ynlûkingsynformaasje ophelje. Ferrin en in net fertroude útjouwer binne wer oare problemen. Allinnich de ophelfflater freget om it folgjen fan in ûntbrekkende rûte nei in status-URL.
Foar dy flater identifisearje trije dingen tagelyk: de URL dy't ophelle wurdt, de komponint dy't it opheljen docht en de identiteit fan syn proses. Dat in browser de URL suksesfol iepenet ûnder jo ynteraktive akkount bewiist net dat in tsjinst him by deselde proxy ferifiearje kin.
As de identifisearre komponint WinHTTP brûkt, ûndersykje dan it belied dat dêrfoar jildt. Statyske proxykonfiguraasje en automatyske proxy-evaluaasje per URL binne aparte meganismen. Pas de stipe konfiguraasje ta foar it bedoelde akkount; it kopiearjen fan browserynstellingen of it feroarjen fan in net-relatearre runtime kin it werklike opheljen ûnoantaast litte.
Yn .NET regelet UrlRetrievalTimeout op it keatlingbelied in wachttijd foar online ferifikaasje of CRL-opheljen. It ferlingjen fan 'e gewoane HTTP-responstiid ferlinget dy selde timer net, en it ferlingjen fan 'e opheltimer jout gjin proxybewizen of in rûte.
In HTTPS-proxy kin dizze ôfhinklikens sichtber meitsje noch foar de TLS fan 'e bestimming: fertrouwen yn 'e proxyferbining kin sels ynlûkingsynformaasje ophelje moatte. Werstel de stipe opheltagong en de fertrouwensregeling yn dy faze. It útskeakeljen fan ynlûkingskontrôle feroaret it sertifikaatbelied; it werstelt it mislearre opheljen net.