Kiun flankon de la inspekta prokurilo malakceptis la atestilo?

La kliento fidas la aprobitan inspektan prokurilon. La peto tamen malsukcesas pro atestila eraro. Ambaŭ faktoj povas esti veraj: tiu prokurilo havas alian TLS-rilaton por validigi.

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

En interkapta aranĝo, la peranto finas la TLS de la kliento kaj kreas sian propran konekton pluen. La kliento povas akcepti la atestilon prezentitan ĉe sia flanko, dum la prokurilo malakceptas la atestilon, kiun ĝi ricevas de la retejo.

Legu la eraron de la validiganto

Determinu, kiu procezo raportis la malsukcesan ĉenon aŭ hostnomon. Erarpaĝo generita de la prokurilo povas sukcese atingi la klienton per valida konekto. Ŝanĝi denove la CA-dosieron de la kliento ne ĝisdatigas la supran fidagordon de la prokurilo.

Mitmproxy, ekzemple, dokumentas apartajn suprajn fidopciojn, inkluzive ssl_verify_upstream_trusted_ca. La taŭga administranto povas agordi aprobitan fidon por la supra servo konservante la validigon. Alia prokura produkto bezonas sian respondan interfacon.

Kontrolu ankaŭ la faktan celan nomon kaj la ĉenon. Privata servo sen intera atestilo, eksvalidiĝinta atestilo kaj nekonata privata eldonanto postulas malsamajn riparojn. Intencita escepto por unu privata servo ne silente fariĝu tutmonda akcepto de ĉiu atestilo.

Ordinara CONNECT-tunelo estas malsama

Malhela plusenda tunelo ne dividas la celan TLS tiamaniere. La aplikaĵo ordinare mem intertraktas kaj validigas tiun TLS-sesion de fino al fino. Unue establu, ĉu interkaptado efektive estas parto de la vojo, anstataŭ apliki inspektajn prokurajn agordojn al ajna peranto.

Registru la du validigajn rezultojn aparte. „La prokura atestilo estas fidata“ respondas la demandon flanke de la kliento; ĝi ne atestas, kion la prokurilo vidis kiam ĝi konektiĝis supren.