Śledzenie awarii proxy w kontrolach certyfikatów CRL i OCSP
Śledź pobieranie CRL lub OCSP na koncie weryfikatora, gdy aplikacja dociera do swojego proxy, ale walidacja certyfikatu nie może się zakończyć.
Żądanie witryny może dotrzeć do swojego proxy i mimo to się nie udać, ponieważ weryfikacja certyfikatu wymaga jeszcze jednego żądania sieciowego. Pobieranie CRL lub OCSP może przebiegać przez komponent platformy o innym koncie i innej polityce proxy niż klient HTTP aplikacji.
Zacznij od dokładnego błędu łańcucha. Revoked znaczy co innego niż nie można uzyskać bieżących informacji o unieważnieniu. Wygaśnięcie i niezaufany wystawca to znów inne problemy. Tylko błąd pobierania wymaga śledzenia brakującej trasy do adresu URL stanu.
Dla tego błędu ustal trzy rzeczy naraz: pobierany adres URL, komponent wykonujący pobieranie i tożsamość jego procesu. To, że przeglądarka otwiera adres URL na Twoim koncie interakcyjnym, nie dowodzi, że usługa może uwierzytelnić się w tym samym proxy.
Jeśli zidentyfikowany komponent używa WinHTTP, zbadaj politykę, która go dotyczy. Statyczna konfiguracja proxy i automatyczna ocena proxy na podstawie adresu URL to odrębne mechanizmy. Zastosuj obsługiwaną konfigurację dla właściwego konta; kopiowanie ustawień przeglądarki lub zmiana niepowiązanego środowiska uruchomieniowego może pozostawić faktyczne pobieranie nietknięte.
W .NET UrlRetrievalTimeout w polityce łańcucha steruje oczekiwaniem na weryfikację online lub pobranie CRL. Wydłużenie zwykłego limitu odpowiedzi HTTP nie wydłuża tego samego licznika, a wydłużenie licznika pobierania nie dostarcza poświadczeń proxy ani trasy.
Proxy HTTPS może uwidocznić tę zależność jeszcze przed TLS do miejsca docelowego: zaufanie do połączenia proxy samo może wymagać pobrania informacji o unieważnieniu. Przywróć obsługiwany dostęp do pobierania i układ zaufania na tym etapie. Wyłączenie kontroli unieważnienia zmienia politykę certyfikatów; nie przywraca nieudanego pobierania.