Az ellenőrző proxy melyik oldala utasította el a tanúsítványt?

Az ügyfél megbízik a jóváhagyott ellenőrző proxyban. A kérés mégis tanúsítványhiba miatt hiúsul meg. Mindkét tény igaz lehet: annak a proxynak van még egy ellenőrizendő TLS-kapcsolata.

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

Elfogó elrendezésben a közvetítő lezárja az ügyfél TLS-ét, és saját kapcsolatot hoz létre tovább. Az ügyfél elfogadhatja a saját oldalán bemutatott tanúsítványt, miközben a proxy elutasítja a webhelytől kapott tanúsítványt.

Olvassa el az ellenőrző hibáját

Állapítsa meg, melyik folyamat jelentette a sikertelen láncot vagy állomásnevet. A proxy által előállított hibaoldal érvényes kapcsolaton keresztül sikeresen elérheti az ügyfelet. Az ügyfél CA-fájljának ismételt módosítása nem frissíti a proxy felső irányú bizalmi konfigurációját.

A Mitmproxy például külön felső irányú bizalmi beállításokat dokumentál, köztük a ssl_verify_upstream_trusted_ca lehetőséget. Az illetékes rendszergazda jóváhagyott bizalmat állíthat be a felső irányú szolgáltatáshoz az ellenőrzés megtartása mellett. Egy másik proxyterméknek a saját megfelelő felületére van szükség.

Ellenőrizze a tényleges célnevet és a láncot is. A köztes tanúsítvány nélküli magánszolgáltatás, a lejárt tanúsítvány és az ismeretlen magánkiadó különböző javításokat igényel. Egy magánszolgáltatásra szánt kivétel nem válhat csendben minden tanúsítvány globális elfogadásává.

Az egyszerű CONNECT-alagút más

Az átlátszatlan továbbítóalagút nem bontja fel így a cél TLS-ét. Az alkalmazás általában maga tárgyalja és ellenőrzi azt a végpontok közötti TLS-munkamenetet. Először állapítsa meg, hogy az elfogás valóban része-e az útvonalnak, ahelyett hogy ellenőrző proxy beállításokat alkalmazna bármely közvetítőre.

Rögzítse a két ellenőrzési eredményt külön. A „A proxy tanúsítványa megbízható” az ügyféloldali kérdésre válaszol; nem tanúsítja, mit látott a proxy, amikor felfelé kapcsolódott.