Que lado do proxy de inspección rexeitou o certificado?

O cliente confía no proxy de inspección aprobado. A solicitude segue fallando por un erro de certificado. Ambos os feitos poden ser certos: ese proxy ten outra relación TLS que verificar.

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

Nun arranxo de interceptación, o intermediario termina o TLS do cliente e crea a súa propia conexión cara adiante. O cliente pode aceptar o certificado presentado do seu lado mentres o proxy rexeita o certificado que recibe do sitio web.

Lea o erro do verificador

Determine que proceso informou da cadea ou do nome de host fallidos. Unha páxina de erro xerada polo proxy pode chegar ao cliente con éxito mediante unha conexión válida. Volver cambiar o ficheiro CA do cliente non actualiza a configuración de confianza ascendente do proxy.

Mitmproxy, por exemplo, documenta opcións separadas de confianza ascendente, incluída ssl_verify_upstream_trusted_ca. O administrador axeitado pode configurar unha confianza aprobada para o servizo ascendente mantendo a verificación. Outro produto de proxy necesita a súa interface correspondente.

Comprobe tamén o nome real de destino e a cadea. Un servizo privado ao que lle falta un intermedio, un certificado caducado e un emisor privado non recoñecido requiren reparacións distintas. Unha excepción prevista para un servizo privado non debería converterse en silencio nunha aceptación global de todos os certificados.

Un túnel CONNECT simple é diferente

Un túnel de reenvío opaco non divide o TLS de destino deste xeito. Normalmente a aplicación negocia e verifica ela mesma esa sesión TLS de extremo a extremo. Primeiro determine se a interceptación forma realmente parte da ruta, en lugar de aplicar a configuración do proxy de inspección a calquera intermediario.

Rexistra os dous resultados de verificación por separado. «Confíase no certificado do proxy» responde á pregunta do lado do cliente; non certifica o que viu o proxy ao conectarse cara arriba.