Kumb inspekteerimisproksi pool sertifikaadi tagasi lükkas?

Klient usaldab heakskiidetud inspekteerimisproksit. Päring siiski ebaõnnestub sertifikaadivea tõttu. Mõlemad faktid võivad olla tõesed: sellel proksil on veel üks TLS-suhe, mida kontrollida.

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

Püüdmise korral lõpetab vahendaja kliendi TLS-i ja loob oma ühenduse edasi. Klient võib aktsepteerida tema poolel esitatud sertifikaati, samal ajal kui proksi lükkab tagasi veebisaidilt saadud sertifikaadi.

Lugege kontrollija viga

Tehke kindlaks, milline protsess teatas ebaõnnestunud ahelast või hostinimest. Proksi loodud vealeht võib jõuda kliendini edukalt üle kehtiva ühenduse. Kliendi CA-faili uuesti muutmine ei uuenda proksi ülesvoolu usalduse konfiguratsiooni.

Näiteks Mitmproxy dokumenteerib eraldi ülesvoolu usalduse valikud, sealhulgas ssl_verify_upstream_trusted_ca. Asjakohane administraator saab ülesvoolu teenuse jaoks seadistada heakskiidetud usalduse, säilitades kontrolli. Teine proksitoode vajab oma vastavat liidest.

Kontrollige ka tegelikku sihtnime ja ahelat. Privaatteenus, millel puudub vahesertifikaat, aegunud sertifikaat ja tundmatu privaatne väljaandja nõuavad erinevaid parandusi. Ühe privaatteenuse jaoks mõeldud erand ei tohiks vaikselt muutuda kõigi sertifikaatide üleilmskeks aktsepteerimiseks.

Tavaline CONNECT-tunnel on erinev

Läbipaistmatu edastustunnel ei jaga sihtkoha TLS-i sel viisil. Rakendus tavaliselt ise läbiräägib ja kontrollib seda otsast otsani TLS-seanssi. Tehke esmalt kindlaks, kas püüdmine on tõesti marsruudi osa, selle asemel et rakendada inspekteerimisproksi seadeid mis tahes vahendajale.

Salvestage kaks kontrollitulemust eraldi. „Proksi sertifikaat on usaldusväärne“ vastab kliendipoolsele küsimusele; see ei tõenda, mida proksi nägi ülesvoolu ühendudes.