Vilken sida av inspektionsproxyn avvisade certifikatet?

Klienten litar på den godkända inspektionsproxyn. Begäran misslyckas ändå på grund av ett certifikatfel. Båda sakerna kan vara sanna: den proxyn har en annan TLS-relation att verifiera.

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

Vid avlyssning avslutar mellanledet klientens TLS och bygger sin egen anslutning vidare. Klienten kan acceptera certifikatet som presenteras på dess sida, medan proxyn avvisar certifikatet den tar emot från webbplatsen.

Läs verifierarens fel

Avgör vilken process som rapporterade den misslyckade kedjan eller värdnamnet. En felsida som proxyn genererar kan nå klienten med framgång över en giltig anslutning. Att ändra klientens CA-fil igen uppdaterar inte proxyns uppströmsförtroendekonfiguration.

Mitmproxy dokumenterar till exempel separata uppströmsförtroendealternativ, inklusive ssl_verify_upstream_trusted_ca. Rätt administratör kan konfigurera godkänt förtroende för uppströmstjänsten och behålla verifieringen. En annan proxyprodukt behöver sitt motsvarande gränssnitt.

Kontrollera också det faktiska destinationsnamnet och kedjan. En privat tjänst utan mellanliggande certifikat, ett utgånget certifikat och en okänd privat utfärdare kräver olika åtgärder. Ett avsett undantag för en privat tjänst bör inte tyst bli ett globalt accepterande av varje certifikat.

En vanlig CONNECT-tunnel är annorlunda

En ogenomskinlig vidarebefordringstunnel delar inte destinationens TLS på detta sätt. Applikationen förhandlar och verifierar vanligtvis själv den ände-till-ände-TLS-sessionen. Fastställ först om avlyssningen faktiskt är en del av vägen, i stället för att tillämpa inspektionsproxyinställningar på vilken mellanhand som helst.

Registrera de två verifieringsresultaten separat. ”Proxyns certifikat är betrott” svarar på frågan på klientsidan; det intygar inte vad proxyn såg när den anslöt uppströms.