Spurado de prokuraj fiaskoj en kontroloj de atestiloj CRL kaj OCSP
Spuru la akiron de CRL aŭ OCSP sub la konto de la kontrolanto kiam la aplikaĵo atingas sian prokurilon sed la atestila validigo ne povas finiĝi.
Peto al retejo povas atingi sian prokurilon kaj tamen fiaski ĉar atestila kontrolo bezonas alian retan peton. Akiro de CRL aŭ OCSP povas okazi per platforma komponanto kun alia konto kaj prokura politiko ol tiu de la HTTP-kliento de la aplikaĵo.
Komencu per la preciza ĉena eraro. Revokita signifas ion alian ol ne povas akiri aktualan revokan informon. Eksvalidiĝo kaj nefidinda eldoninto estas denove aliaj problemoj. Nur la akirfiasko postulas spuradon de mankanta vojo al statusa URL.
Por tiu fiasko, identigu tri aferojn kune: la akiratan URL, la komponanton kiu faras la akiron kaj ĝian procesan identecon. Tio ke retumilo malfermas la URL sukcese sub via interaga konto ne pruvas, ke servo povas aŭtentigi sin al la sama prokurilo.
Se la identigita komponanto uzas WinHTTP, ekzamenu la politikon aplikeblan al ĝi. Statika prokura agordo kaj aŭtomata prokura taksado laŭ URL estas apartaj mekanismoj. Apliku la subtenatan agordon por la celita konto; kopii retumilajn agordojn aŭ ŝanĝi nerilatan rulmedianon povas lasi la faktan akiron netuŝita.
En .NET, UrlRetrievalTimeout sur la ĉena politiko regas atendo por interreta kontrolado aŭ akiro de CRL. Etendi la ordinaran HTTP-respondan limtempon ne etendas tiun saman tempigilon, kaj etendi la akiran tempigilon ne donas prokurajn akreditaĵojn nek vojon.
HTTPS-prokurilo povas videbligi ĉi tiun dependon eĉ antaŭ la celloka TLS: fido al la prokura konekto mem povas postuli revokan informakiron. Restarigu la subtenatan akiran aliron kaj fidan aranĝon en tiu stadio. Malŝalti revokan kontroladon ŝanĝas la atestilan politikon; ĝi ne restarigas la fiaskintan akiron.