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