Hvilken side af inspektionsproxien afviste certifikatet?

Klienten stoler på den godkendte inspektionsproxy. Anmodningen fejler stadig på grund af en certifikatfejl. Begge forhold kan være sande: proxien har endnu et TLS-forhold, der skal verificeres.

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

I en interceptopsætning afslutter mellemleddet klientens TLS og opretter sin egen forbindelse videre. Klienten kan acceptere certifikatet, der præsenteres på dens side, mens proxien afviser certifikatet, den modtager fra webstedet.

Læs verifikatorens fejl

Afgør, hvilken proces der rapporterede den fejlede kæde eller det fejlede værtsnavn. En fejlside genereret af proxien kan nå klienten med succes over en gyldig forbindelse. At ændre klientens CA-fil igen opdaterer ikke proxiens opstrøms tillidskonfiguration.

Mitmproxy dokumenterer for eksempel separate opstrøms tillidsindstillinger, herunder ssl_verify_upstream_trusted_ca. Den rette administrator kan konfigurere godkendt tillid til opstrømstjenesten og samtidig bevare verifikationen. Et andet proxyprodukt har brug for sin tilsvarende grænseflade.

Kontrollér også det faktiske destinationsnavn og kæden. En privat tjeneste uden et mellemcertifikat, et udløbet certifikat og en ukendt privat udsteder kræver forskellige rettelser. En tilsigtet undtagelse for én privat tjeneste bør ikke stille blive en global accept af ethvert certifikat.

En almindelig CONNECT-tunnel er anderledes

En uigennemsigtig videresendelsestunnel opdeler ikke destinationens TLS på denne måde. Applikationen forhandler og verificerer normalt selv den ende-til-ende TLS-session. Fastslå først, om intercept faktisk er en del af ruten, i stedet for at anvende indstillinger for inspektionsproxy på enhver mellemmand.

Registrér de to verifikationsresultater hver for sig. „Proxiens certifikat er betroet“ besvarer spørgsmålet på klientsiden; det bekræfter ikke, hvad proxien så, da den koblede opstrøms.