Gjurmimi i dështimeve të proxy-t në kontrollet e certifikatave CRL dhe OCSP

Një kërkesë drejt një faqeje mund të arrijë proxy-n e vet dhe prapë të dështojë, sepse verifikimi i certifikatës kërkon një kërkesë tjetër rrjeti. Marrja e CRL ose OCSP mund të kalojë përmes një komponenti të platformës me llogari dhe politikë proxy të ndryshme nga klienti HTTP i aplikacionit.

Filloni me gabimin e saktë të zinxhirit. Revoked do të thotë diçka tjetër nga nuk mund të merret informacioni aktual i revokimit. Skadimi dhe një lëshues i pabesuar janë prapë probleme të tjera. Vetëm dështimi i marrjes kërkon gjurmimin e një rruge që mungon drejt një URL statusi.

Për atë dështim, identifikoni tri gjëra së bashku: URL-në që merret, komponentin që e kryen marrjen dhe identitetin e procesit të tij. Fakti që një shfletues e hap URL-në me sukses nën llogarinë tuaj interaktive nuk provon që një shërbim mund të autentikohet në të njëjtin proxy.

Nëse komponenti i identifikuar përdor WinHTTP, shqyrtoni politikën që zbatohet për të. Konfigurimi statik i proxy-t dhe vlerësimi automatik i proxy-t sipas URL-së janë mekanizma të veçantë. Zbatoni konfigurimin e mbështetur për llogarinë e synuar; kopjimi i cilësimeve të shfletuesit ose ndryshimi i një runtime të palidhur mund ta lërë marrjen reale të paprekur.

Në .NET, UrlRetrievalTimeout në politikën e zinxhirit kontrollon një pritje për verifikim në internet ose për marrjen e CRL. Zgjatja e afatit të zakonshëm të përgjigjes HTTP nuk e zgjat të njëjtin kohëmatës, dhe zgjatja e kohëmatësit të marrjes nuk siguron kredenciale proxy ose një rrugë.

Një proxy HTTPS mund ta bëjë këtë varësi të dukshme që përpara TLS drejt destinacionit: besimi në lidhjen proxy mund të kërkojë vetë marrjen e revokimit. Riktheni aksesin e mbështetur të marrjes dhe rregullimin e besimit në atë fazë. Çaktivizimi i kontrollit të revokimit ndryshon politikën e certifikatave; nuk e rikthen marrjen e dështuar.