Antes de alterar um pacote de CAs, identifique qual negociação TLS falhou. O certificado do proxy e o do site podem ser verificados em conexões distintas.

Proxy e destinoVerificações de TLS
Proxy HTTP para um destino HTTPSDepois de CONNECT, verifique o certificado do destino pelo túnel.
Proxy HTTPS para um destino HTTPSPrimeiro verifique o TLS com o proxy; após a abertura do túnel, verifique a sessão TLS separada com o destino.

Use o rastreamento detalhado para identificar o nome de host solicitado e a última negociação concluída. Uma falha de certificado do proxy HTTPS pode ocorrer antes de o site ser contatado. Confira o nome esperado para essa conexão, o período de validade do certificado, o relógio local, a cadeia esperada e o repositório de confiança aprovado. Inclua na investigação qualquer interceptação TLS configurada de propósito ou certificado raiz adicionado.

O curl oferece opções de CA separadas para as duas conexões:

curl --proxy https://proxy.example:8443 --proxy-cacert proxy-ca.pem --cacert site-ca.pem https://example.com/

--proxy-cacert fornece a base de confiança para o proxy; --cacert, para o destino. Substitua o endpoint e os arquivos do exemplo pelos valores da configuração de confiança pretendida. Pacotes personalizados são desnecessários quando a confiança do sistema já é suficiente.

Trocar o nome de host por um IP arbitrário altera a correspondência do certificado. Ignorar a verificação pode esconder a falha sem confirmar a identidade da outra ponta. Para um proxy desconhecido, um pedido para instalar a CA raiz dele não é motivo suficiente para confiar nele.

Uma conexão recusada na porta ou um CONNECT rejeitado pertencem a uma etapa anterior; mudar certificados não resolve isso. Por outro lado, depois de o TLS do destino ser verificado, um erro HTTP do site faz parte da resposta recebida, e não de outro ajuste de CA.

Artigos relacionados