Að rekja proxývillur í CRL- og OCSP-skilríkjaprófunum

Beiðni til vefsíðu getur náð proxýinu sínu og samt mistekist því skilríkisstaðfesting þarf aðra netbeiðni. CRL- eða OCSP-sókn getur farið um kerfishluta með öðrum reikningi og proxýstefnu en HTTP-biðlarinn í forritinu.

Byrjaðu á nákvæmri keðjuvillunni. Hekkt þýðir eitthvað annað en getur ekki sótt núverandi upplýsingar um afturköllun. Gildistími og ótraustur útgefandi eru aftur aðrar vandamál. Aðeins sóknarmistökin krefjast þess að rekja vantaða leið að stöðu-URL.

Fyrir þá mistökin skaltu greina þrjá hluti saman: URL-ið sem er sótt, hlutinn sem sækir og auðkenni ferlis hans. Það að vafri opni URL-ið með góðum árangri undir gagnvirka reikningnum þínum sannar ekki að þjónusta geti auðkennt sig við sama proxý.

Ef greindi hluturinn notar WinHTTP skaltu skoða stefnuna sem gildir fyrir hann. Stök proxýstilling og sjálfvirk proxýmat á hverju URL eru aðskildir ferlar. Beittu studdu stillingunni fyrir ætlaðan reikning; að afrita vafrastillingar eða breyta ótengdu keyrsluumhverfi getur skilið raunverulegu sóknina ósnortna.

Í .NET stýrir UrlRetrievalTimeout á keðjustefnunni bið eftir netstaðfestingu eða CRL-sókn. Að lengja venjulega HTTP-svartímamörk lengir ekki sama tímamælinn, og að lengja sóknartímamælinn veitir hvorki proxýskilríki né leið.

HTTPS-proxý getur gert þessa fíkni sýnilega jafnvel fyrir TLS áfangastaðar: traust á proxýtengingunni getur sjálft krafist sóknar upplýsinga um afturköllun. Endurheimtu studda sóknaraðganginn og traustskipulagið á því stigi. Að slökkva á afturköllunarprófun breytir skilríkjastefnunni; það endurheimtir ekki misheppnuðu sóknina.