Care parte a proxy-ului de inspecție a respins certificatul?

Clientul are încredere în proxy-ul de inspecție aprobat. Cererea eșuează totuși din cauza unei erori de certificat. Ambele fapte pot fi adevărate: acel proxy are o altă relație TLS de verificat.

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

Într-un aranjament de interceptare, intermediarul încheie TLS-ul clientului și își creează propria conexiune mai departe. Clientul poate accepta certificatul prezentat de partea sa, în timp ce proxy-ul respinge certificatul primit de la site.

Citiți eroarea verificatorului

Determinați ce proces a raportat lanțul sau numele de gazdă eșuat. O pagină de eroare generată de proxy poate ajunge la client cu succes printr-o conexiune validă. Modificarea din nou a fișierului CA al clientului nu actualizează configurația de încredere ascendentă a proxy-ului.

De exemplu, Mitmproxy documentează opțiuni separate de încredere ascendentă, inclusiv ssl_verify_upstream_trusted_ca. Administratorul potrivit poate configura o încredere aprobată pentru serviciul ascendent păstrând verificarea. Un alt produs proxy are nevoie de interfața sa corespunzătoare.

Verificați și numele real al destinației și lanțul. Un serviciu privat fără un intermediar, un certificat expirat și un emitent privat nerecunoscut necesită reparații diferite. O excepție intenționată pentru un serviciu privat nu ar trebui să devină în tăcere o acceptare globală a fiecărui certificat.

Un tunel CONNECT simplu este diferit

Un tunel de redirecționare opac nu separă TLS-ul destinației în acest fel. Aplicația negociază și verifică de obicei ea însăși acea sesiune TLS cap la cap. Stabiliți mai întâi dacă interceptarea face parte cu adevărat din rută, în loc să aplicați setările proxy-ului de inspecție oricărui intermediar.

Înregistrați cele două rezultate ale verificării separat. „Certificatul proxy-ului este de încredere” răspunde la întrebarea din partea clientului; nu certifică ce a văzut proxy-ul când s-a conectat ascendent.