Klient ufa zatwierdzonemu proxy inspekcji. Żądanie nadal kończy się niepowodzeniem z powodu błędu certyfikatu. Oba fakty mogą być prawdziwe: to proxy ma jeszcze jedną relację TLS do zweryfikowania.

client -- TLS to approved intermediary -- proxy -- TLS to website -- destination

W układzie przechwytywania pośrednik kończy TLS klienta i tworzy własne połączenie dalej. Klient może zaakceptować certyfikat przedstawiony po jego stronie, podczas gdy proxy odrzuca certyfikat otrzymany od witryny.

Przeczytaj błąd weryfikatora

Ustal, który proces zgłosił nieudany łańcuch lub nazwę hosta. Strona błędu wygenerowana przez proxy może z powodzeniem dotrzeć do klienta przez ważne połączenie. Ponowna zmiana pliku CA klienta nie aktualizuje konfiguracji zaufania proxy do strony nadrzędnej.

Na przykład Mitmproxy dokumentuje osobne opcje zaufania do strony nadrzędnej, w tym ssl_verify_upstream_trusted_ca. Właściwy administrator może skonfigurować zatwierdzone zaufanie dla usługi nadrzędnej, zachowując weryfikację. Inny produkt proxy potrzebuje swojego odpowiedniego interfejsu.

Sprawdź także rzeczywistą nazwę miejsca docelowego i łańcuch. Usługa prywatna bez certyfikatu pośredniego, wygasły certyfikat i nierozpoznany prywatny wystawca wymagają różnych napraw. Zamierzony wyjątek dla jednej usługi prywatnej nie powinien po cichu stać się globalną akceptacją każdego certyfikatu.

Zwykły tunel CONNECT jest inny

Nieprzezroczysty tunel przekazywania nie dzieli TLS miejsca docelowego w ten sposób. Aplikacja zwykle sama negocjuje i weryfikuje tę sesję TLS od końca do końca. Najpierw ustal, czy przechwytywanie jest rzeczywiście częścią trasy, zamiast stosować ustawienia proxy inspekcji do dowolnego pośrednika.

Zapisz oba wyniki weryfikacji osobno. „Certyfikat proxy jest zaufany” odpowiada na pytanie po stronie klienta; nie zaświadcza, co proxy widziało, łącząc się w górę.

Powiązane artykuły