Která strana inspekčního proxy odmítla certifikát?

Klient důvěřuje schválené inspekční proxy. Požadavek přesto selhává kvůli chybě certifikátu. Obě skutečnosti mohou platit současně: tato proxy má další relaci TLS, kterou je třeba ověřit.

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

Při zachytávání ukončí prostředník TLS klienta a vytvoří si vlastní spojení dál. Klient může přijmout certifikát předložený na jeho straně, zatímco proxy odmítá certifikát, který dostává od webu.

Přečtěte si chybu ověřovatele

Určete, který proces nahlásil selhání řetězce nebo názvu hostitele. Chybová stránka vygenerovaná proxy se může ke klientovi úspěšně dostat přes platné spojení. Další změna souboru CA klienta neaktualizuje konfiguraci důvěry proxy vůči nadřazenému serveru.

Například Mitmproxy dokumentuje samostatné volby důvěry pro nadřazený server, včetně ssl_verify_upstream_trusted_ca. Příslušný správce může nastavit schválenou důvěru pro nadřazenou službu a přitom zachovat ověřování. Jiný proxy produkt potřebuje své odpovídající rozhraní.

Zkontrolujte také skutečný název cíle a řetězec. Soukromá služba bez zprostředkujícího certifikátu, prošlý certifikát a nerozpoznaný soukromý vydavatel vyžadují různá opravení. Zamýšlená výjimka pro jednu soukromou službu by se neměla tiše stát globálním přijetím každého certifikátu.

Obyčejný tunel CONNECT je jiný

Neprůhledný tunel pro předávání nerozděluje TLS cíle tímto způsobem. Aplikace obvykle sama vyjednává a ověřuje tuto relaci TLS od konce ke konci. Nejprve zjistěte, zda je zachytávání skutečně součástí trasy, místo abyste nastavení inspekční proxy uplatňovali na jakéhokoli prostředníka.

Zaznamenejte oba výsledky ověření odděleně. „Certifikát proxy je důvěryhodný“ odpovídá na otázku na straně klienta; nedosvědčuje, co proxy viděla, když se připojovala dál.