Katera stran nadzornega posrednika je zavrnila potrdilo?

Odjemalec zaupa odobrenemu nadzornemu posredniku. Zahteva vseeno spodleti zaradi napake s potrdilom. Obe dejstvi lahko veljata: ta posrednik ima še en odnos TLS, ki ga je treba preveriti.

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

Pri prestrezanju posrednik zaključi TLS odjemalca in ustvari svojo povezavo naprej. Odjemalec lahko sprejme potrdilo, predstavljeno na njegovi strani, medtem ko posrednik zavrne potrdilo, ki ga prejme s spletnega mesta.

Preberite napako preverjevalnika

Ugotovite, kateri proces je poročal o neuspeli verigi ali imenu gostitelja. Stran z napako, ki jo ustvari posrednik, lahko odjemalca doseže uspešno prek veljavne povezave. Ponovna sprememba datoteke CA odjemalca ne posodobi konfiguracije zaupanja posrednika navzgor.

Mitmproxy na primer dokumentira ločene možnosti zaupanja navzgor, vključno z ssl_verify_upstream_trusted_ca. Pristojni skrbnik lahko nastavi odobreno zaupanje za storitev navzgor, pri čemer preverjanje ohrani. Drug izdelek posrednika potrebuje svoj ustrezen vmesnik.

Preverite tudi dejansko ime cilja in verigo. Zasebna storitev brez vmesnega potrdila, poteklo potrdilo in neznani zasebni izdajatelj zahtevajo različna popravila. Predvidena izjema za eno zasebno storitev ne sme tiho postati globalno sprejemanje vsakega potrdila.

Navaden predor CONNECT je drugačen

Neprozoren predor za posredovanje ne razdeli TLS cilja na ta način. Aplikacija običajno sama pogaja in preverja to sejo TLS od konca do konca. Najprej ugotovite, ali je prestrezanje res del poti, namesto da nastavitve nadzornega posrednika uporabite za katerega koli posrednika.

Zabeležite oba rezultata preverjanja ločeno. „Potrdilu posrednika je mogoče zaupati“ odgovori na vprašanje na strani odjemalca; ne potrjuje, kaj je posrednik videl, ko se je povezoval navzgor.