Proxyfouten traceren bij CRL- en OCSP-certificaatcontroles
Traceer het ophalen van CRL of OCSP onder het account van de verifier wanneer de toepassing de proxy bereikt maar certificaatvalidatie niet kan worden voltooid.
Een websiteverzoek kan de proxy bereiken en toch mislukken omdat certificaatverificatie nog een netwerkverzoek nodig heeft. Een CRL- of OCSP-ophaling kan via een platformcomponent lopen met een ander account en proxybeleid dan de HTTP-client van de toepassing.
Begin met de exacte ketenfout. Revoked betekent iets anders dan kan geen actuele intrekkingsinformatie verkrijgen. Verloop en een niet-vertrouwde uitgever zijn weer andere problemen. Alleen de ophaalfout vraagt om het traceren van een ontbrekende route naar een status-URL.
Bepaal voor die fout drie dingen samen: de URL die wordt opgehaald, de component die het ophalen doet en de procesidentiteit daarvan. Dat een browser de URL onder uw interactieve account opent, bewijst niet dat een service zich bij dezelfde proxy kan authenticeren.
Als de geïdentificeerde component WinHTTP gebruikt, onderzoek dan het beleid dat ervoor geldt. Statische proxyconfiguratie en automatische proxy-evaluatie per URL zijn afzonderlijke mechanismen. Pas de ondersteunde configuratie toe voor het beoogde account; het kopiëren van browserinstellingen of het wijzigen van een niet-gerelateerde runtime kan de feitelijke ophaling onaangeroerd laten.
In .NET beheert UrlRetrievalTimeout op het ketenbeleid een wachttijd voor onlineverificatie of CRL-ophaling. Het verlengen van de gewone HTTP-responstime-out verlengt diezelfde timer niet, en het verlengen van de ophaaltimer levert geen proxyreferenties of een route op.
Een HTTPS-proxy kan deze afhankelijkheid al zichtbaar maken vóór TLS naar de bestemming: vertrouwen in de proxyverbinding kan zelf intrekkingsophaling vereisen. Herstel de ondersteunde ophaaltoegang en de vertrouwensregeling in die fase. Het uitschakelen van intrekkingscontrole wijzigt het certificaatbeleid; het herstelt de mislukte ophaling niet.