Koja strana inspekcijskog proxyja je odbila certifikat?

Klijent vjeruje odobrenom inspekcijskom proxyju. Zahtjev ipak ne prolazi zbog greške certifikata. Obje činjenice mogu biti istinite: taj proxy ima još jedan TLS odnos koji treba provjeriti.

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

U aranžmanu presretanja posrednik prekida klijentov TLS i stvara vlastitu vezu dalje. Klijent može prihvatiti certifikat predstavljen na njegovoj strani, dok proxy odbija certifikat koji dobiva od web-mjesta.

Pročitajte grešku provjeravatelja

Utvrdite koji je proces prijavio neuspjeli lanac ili ime hosta. Stranica greške koju generira proxy može uspješno stići do klijenta preko valjane veze. Ponovna izmjena klijentove CA datoteke ne ažurira proxyjevu konfiguraciju povjerenja prema izvoru.

Mitmproxy, na primjer, dokumentira zasebne opcije povjerenja prema izvoru, uključujući ssl_verify_upstream_trusted_ca. Odgovarajući administrator može postaviti odobreno povjerenje za uslugu prema izvoru uz zadržavanje provjere. Drugi proxy proizvod treba svoje odgovarajuće sučelje.

Provjerite i stvarno ime odredišta i lanac. Privatna usluga bez posredničkog certifikata, istekao certifikat i nepoznati privatni izdavatelj zahtijevaju različite popravke. Namjeravana iznimka za jednu privatnu uslugu ne smije tiho postati globalno prihvaćanje svakog certifikata.

Obični CONNECT tunel je drugačiji

Neprozirni tunel za prosljeđivanje ne dijeli TLS odredišta na taj način. Aplikacija obično sama pregovara i provjerava tu TLS sesiju od kraja do kraja. Najprije utvrdite je li presretanje uopće dio rute, umjesto da postavke inspekcijskog proxyja primjenjujete na bilo koji posrednik.

Zabilježite dva rezultata provjere odvojeno. „Proxyjev certifikat je pouzdan“ odgovara na pitanje s klijentske strane; ne potvrđuje što je proxy vidio kada se povezao prema izvoru.