Kura inspekcijas starpniekservera puse noraidīja sertifikātu?

Klients uzticas apstiprinātajam inspekcijas starpniekserverim. Pieprasījums joprojām neizdodas sertifikāta kļūmes dēļ. Abi fakti var būt patiesi: šim starpniekserverim ir vēl viena TLS attiecība, kas jāpārbauda.

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

Pārtveršanas shēmā starpnieks izbeidz klienta TLS un izveido savu savienojumu tālāk. Klients var pieņemt savā pusē uzrādīto sertifikātu, kamēr starpniekserveris noraida no vietnes saņemto sertifikātu.

Izlasiet pārbaudītāja kļūdu

Nosakiet, kurš process ziņoja par neizdevušos ķēdi vai resursdatora nosaukumu. Starpniekservera ģenerētā kļūdas lapa var sasniegt klientu sekmīgi pa derīgu savienojumu. Klienta CA faila atkārtota maiņa neatjaunina starpniekservera augšupstraumes uzticēšanās konfigurāciju.

Piemēram, Mitmproxy dokumentē atsevišķas augšupstraumes uzticēšanās opcijas, tostarp ssl_verify_upstream_trusted_ca. Atbilstošais administrators var iestatīt apstiprinātu uzticēšanos augšupstraumes pakalpojumam, saglabājot verifikāciju. Citam starpniekservera produktam nepieciešama sava atbilstošā saskarne.

Pārbaudiet arī faktisko galamērķa nosaukumu un ķēdi. Privāts pakalpojums bez starpsertifikāta, beidzies sertifikāts un neatzīts privāts izdevējs prasa dažādus labojumus. Paredzētais izņēmums vienam privātam pakalpojumam nedrīkst klusējot kļūt par visu sertifikātu globālu pieņemšanu.

Parasts CONNECT tunelis ir citāds

Necaurredzams pārsūtīšanas tunelis šādi nesadala galamērķa TLS. Lietojumprogramma parasti pati vienojas un pārbauda šo TLS sesiju no gala līdz galam. Vispirms nosakiet, vai pārtveršana patiešām ir maršruta daļa, nevis piemērojiet inspekcijas starpniekservera iestatījumus jebkuram starpniekam.

Reģistrējiet abus verifikācijas rezultātus atsevišķi. „Starpniekservera sertifikāts ir uzticams“ atbild uz klienta puses jautājumu; tas neliecina, ko starpniekserveris redzēja, kad izveidoja savienojumu augšup.