Адсочванне збояў проксі пры праверках сертыфікатаў CRL і OCSP
Адсочвайце атрыманне CRL або OCSP пад уліковым запісам правяральніка, калі праграма дасягае свайго проксі, але праверка сертыфіката не можа завяршыцца.
Запыт да вэб-сайта можа дасягнуць свайго проксі і ўсё ж пацярпець няўдачу, бо для праверкі сертыфіката патрэбны яшчэ адзін сеткавы запыт. Атрыманне CRL або OCSP можа выконвацца кампанентам платформы з іншым уліковым запісам і іншай палітыкай проксі, чым у HTTP-кліента праграмы.
Пачніце з дакладнай памылкі ланцуга. Адкліканы азначае не тое ж, што немагчыма атрымаць актуальныя звесткі пра адкліканне. Заканчэнне тэрміну дзеяння і недавераны выдавец — гэта зноў іншыя праблемы. Толькі збой атрымання патрабуе адсочвання адсутнага маршруту да URL стану.
Для гэтага збою вызначце тры рэчы разам: URL, які атрымліваецца, кампанент, які выконвае атрыманне, і яго ідэнтычнасць працэсу. Паспяховае адкрыццё URL у браўзеры пад вашым інтэрактыўным уліковым запісам не даказвае, што служба можа аўтэнтыфікавацца на тым жа проксі.
Калі вызначаны кампанент выкарыстоўвае WinHTTP, вывучыце палітыку, якая да яго прымяняецца. Статычная канфігурацыя проксі і аўтаматычная ацэнка проксі для кожнага URL — гэта асобныя механізмы. Прымяніце падтрымліваемую канфігурацыю для патрэбнага ўліковага запісу; капіраванне налад браўзера або змена непавязанага асяроддзя выканання могуць пакінуць фактычнае атрыманне незакранутым.
У .NET UrlRetrievalTimeout у палітыцы ланцуга кіруе чаканнем анлайн-праверкі або атрымання CRL. Падаўжэнне звычайнага тайм-аўту HTTP-адказу не падаўжае гэты ж таймер, а падаўжэнне таймера атрымання не дае ні ўліковых даных проксі, ні маршруту.
HTTPS-проксі можа зрабіць гэтую залежнасць бачнай яшчэ да TLS прызначэння: давер да злучэння з проксі сам можа патрабаваць атрымання звестак пра адкліканне. Аднавіце падтрымліваемы доступ да атрымання і даверныя дамоўленасці на гэтым этапе. Адключэнне праверкі адклікання змяняе палітыку сертыфікатаў; яно не аднаўляе збойнае атрыманне.