Kufuatilia Hitilafu za Proksi katika Ukaguzi wa Vyeti vya CRL na OCSP

Ombi la tovuti linaweza kufikia proksi yake na bado likashindikana kwa sababu uthibitishaji wa cheti unahitaji ombi lingine la mtandao. Upataji wa CRL au OCSP unaweza kupitia sehemu ya jukwaa yenye akaunti na sera ya proksi tofauti na mteja wa HTTP wa programu.

Anza na kosa kamili la mnyororo. Revoked inamaanisha kitu tofauti na haiwezekani kupata taarifa za sasa za ubatilishaji. Kuisha muda na mtoaji asiyeaminika ni matatizo mengine tena. Ni kosa la upataji pekee linalohitaji kufuatilia njia iliyokosekana kuelekea URL ya hali.

Kwa kosa hilo, tambua mambo matatu pamoja: URL inayopatikana, sehemu inayofanya upataji na utambulisho wa mchakato wake. Kivinjari kufungua URL kwa mafanikio chini ya akaunti yako ya mwingiliano hakuthibitishi kuwa huduma inaweza kuthibitisha utambulisho kwenye proksi hiyo hiyo.

Ikiwa sehemu iliyotambuliwa inatumia WinHTTP, chunguza sera inayotumika kwake. Usanidi tuli wa proksi na tathmini ya kiotomatiki ya proksi kwa URL ni taratibu tofauti. Tumia usanidi unaotumika kwa akaunti inayokusudiwa; kunakili mipangilio ya kivinjari au kubadilisha runtime isiyohusiana kunaweza kuacha upataji halisi bila kuguswa.

Katika .NET, UrlRetrievalTimeout kwenye sera ya mnyororo hudhibiti kusubiri uthibitishaji wa mtandaoni au upataji wa CRL. Kuongeza muda wa kawaida wa jibu la HTTP hakuongezi kipima muda hicho hicho, na kuongeza kipima muda cha upataji hakutoa vitambulisho vya proksi au njia.

Proksi ya HTTPS inaweza kufanya utegemezi huu uonekane hata kabla ya TLS ya lengwa: uaminifu wa muunganisho wa proksi wenyewe unaweza kuhitaji upataji wa ubatilishaji. Rejesha ufikiaji wa upataji unaotumika na mpangilio wa uaminifu katika hatua hiyo. Kuzima ukaguzi wa ubatilishaji hubadilisha sera ya vyeti; hakurejeshi upataji ulioshindikana.