Qual lado do proxy de inspeção rejeitou o certificado?

O cliente confia no proxy de inspeção aprovado. O pedido continua a falhar por causa de um erro de certificado. Ambos os factos podem ser verdadeiros: esse proxy tem outra relação TLS a verificar.

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

Num arranjo de interceção, o intermediário termina o TLS do cliente e cria a sua própria ligação em frente. O cliente pode aceitar o certificado apresentado do seu lado enquanto o proxy rejeita o certificado que recebe do sítio web.

Leia o erro do verificador

Determine qual processo reportou a cadeia ou o nome do anfitrião com falha. Uma página de erro gerada pelo proxy pode chegar ao cliente com êxito através de uma ligação válida. Alterar novamente o ficheiro CA do cliente não atualiza a configuração de confiança a montante do proxy.

O Mitmproxy, por exemplo, documenta opções separadas de confiança a montante, incluindo ssl_verify_upstream_trusted_ca. O administrador adequado pode configurar confiança aprovada para o serviço a montante mantendo a verificação. Outro produto de proxy precisa da sua interface correspondente.

Verifique também o nome real do destino e a cadeia. Um serviço privado sem um intermédio, um certificado expirado e um emissor privado não reconhecido exigem reparações diferentes. Uma exceção prevista para um serviço privado não deve tornar-se silenciosamente numa aceitação global de todos os certificados.

Um túnel CONNECT simples é diferente

Um túnel de encaminhamento opaco não divide o TLS do destino desta forma. A aplicação normalmente negocia e verifica ela própria essa sessão TLS de ponta a ponta. Primeiro estabeleça se a interceção faz realmente parte da rota, em vez de aplicar definições do proxy de inspeção a qualquer intermediário.

Registe os dois resultados de verificação separadamente. «O certificado do proxy é fidedigno» responde à questão do lado do cliente; não certifica o que o proxy viu quando se ligou a montante.