Трасування збоїв проксі під час перевірок сертифікатів CRL і OCSP

Запит до сайту може дійти до свого проксі й усе одно завершитися збоєм, бо для перевірки сертифіката потрібен ще один мережевий запит. Отримання CRL або OCSP може виконувати компонент платформи з іншим обліковим записом і іншою політикою проксі, ніж у HTTP-клієнта застосунку.

Почніть із точної помилки ланцюжка. Revoked означає не те саме, що неможливо отримати актуальні відомості про відкликання. Завершення строку та недовірений видавець — це знову інші проблеми. Лише збій отримання вимагає трасування відсутнього маршруту до URL стану.

Для цього збою визначте три речі разом: URL, який отримується, компонент, що виконує отримання, та ідентичність його процесу. Те, що браузер успішно відкриває URL у вашому інтерактивному обліковому записі, не доводить, що служба може автентифікуватися на тому самому проксі.

Якщо визначений компонент використовує WinHTTP, дослідіть політику, застосовну до нього. Статична конфігурація проксі та автоматичне оцінювання проксі для кожного URL — це окремі механізми. Застосуйте підтримувану конфігурацію для потрібного облікового запису; копіювання налаштувань браузера або зміна стороннього середовища виконання може залишити фактичне отримання незміненим.

У .NET UrlRetrievalTimeout у політиці ланцюжка керує очікуванням онлайн-перевірки або отримання CRL. Збільшення звичайного тайм-ауту відповіді HTTP не продовжує той самий таймер, а збільшення таймера отримання не дає облікових даних проксі чи маршруту.

Проксі HTTPS може зробити цю залежність видимою ще до TLS до призначення: довіра до з'єднання з проксі сама може потребувати отримання відомостей про відкликання. Відновіть підтримуваний доступ до отримання та схему довіри на цьому етапі. Вимкнення перевірки відкликання змінює політику сертифікатів; воно не відновлює невдале отримання.