Urmărirea eșecurilor de proxy în verificările certificatelor CRL și OCSP

O cerere către un site poate ajunge la proxy-ul său și totuși eșua, pentru că verificarea certificatului are nevoie de încă o cerere de rețea. Obținerea CRL sau OCSP poate rula printr-o componentă a platformei cu alt cont și altă politică de proxy decât clientul HTTP al aplicației.

Începeți cu eroarea exactă a lanțului. Revoked înseamnă altceva decât nu se poate obține informația curentă de revocare. Expirarea și un emitent neîncrezut sunt din nou alte probleme. Doar eșecul de obținere cere urmărirea unei rute lipsă către un URL de stare.

Pentru acel eșec, identificați trei lucruri împreună: URL-ul obținut, componenta care face obținerea și identitatea procesului acesteia. Faptul că un browser deschide URL-ul cu succes în contul dvs. interactiv nu dovedește că un serviciu se poate autentifica la același proxy.

Dacă componenta identificată folosește WinHTTP, examinați politica aplicabilă acesteia. Configurația statică de proxy și evaluarea automată a proxy-ului pe URL sunt mecanisme separate. Aplicați configurația acceptată pentru contul dorit; copierea setărilor browserului sau modificarea unui runtime nelegat poate lăsa obținerea reală neatinsă.

În .NET, UrlRetrievalTimeout din politica lanțului controlează o așteptare pentru verificarea online sau obținerea CRL. Prelungirea timeout-ului obișnuit de răspuns HTTP nu prelungește același temporizator, iar prelungirea temporizatorului de obținere nu oferă credențiale de proxy sau o rută.

Un proxy HTTPS poate face această dependență vizibilă chiar înainte de TLS către destinație: încrederea în conexiunea la proxy poate necesita ea însăși obținerea informației de revocare. Restabiliți accesul de obținere acceptat și aranjamentul de încredere în acea etapă. Dezactivarea verificării revocării schimbă politica de certificate; nu reface obținerea eșuată.