Erros de verificação TLS em diferentes ferramentas: unknown authority, CERTIFICATE_VERIFY_FAILED, self-signed na cadeia

O que é

Vários clientes TLS descrevem, cada um com seu próprio vocabulário, a mesma falha de fundo: não conseguiram montar uma cadeia entre o certificado do servidor e um certificado em que já confiam. O crypto/x509 do Go relata x509: certificate signed by unknown authority (desde o Go 1.20, com o prefixo tls: failed to verify certificate:). O módulo ssl do Python, que usa o OpenSSL, levanta [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate, um erro documentado na própria referência do módulo. O curl exibe curl: (60) SSL certificate problem: seguido de unable to get local issuer certificate ou self-signed certificate in certificate chain, conforme o ponto exato em que a cadeia se rompe, como descreve a documentação do curl sobre problemas de certificado SSL; o OpenSSL 1.1.1 escreve self signed. O Node.js e o openssl s_client relatam uma cadeia com apenas o certificado folha (leaf), emitido por uma autoridade desconhecida, como unable to verify the first certificate.

Por que importa

A mensagem dá pistas sobre a causa raiz, mas não a identifica de forma confiável, e adivinhar faz perder tempo: um certificado intermediário ausente é um erro de configuração do servidor; uma raiz autoassinada no fim da cadeia é uma CA privada legítima ou, em casos raros, uma interceptação em curso; e nenhum dos dois casos se resolve desativando a verificação.

Como aplicar

• Diagnostique primeiro: openssl s_client -connect host:443 -servername host </dev/null, documentado na página de manual do s_client do OpenSSL, imprime a cadeia de certificados enviada pelo servidor (acrescente -showcerts para ver os blocos PEM completos) e, no final, uma linha Verify return code:. Se a cadeia termina no certificado folha, sem nenhum intermediário, o servidor não está enviando o pacote de certificados intermediários. Se os campos issuer e subject do último certificado são idênticos, a cadeia termina em um certificado autoassinado: ou é a sua própria CA privada/interna, em que o cliente ainda não confia, ou, se você não esperava uma raiz autoassinada, é sinal de que o tráfego pode estar sendo interceptado.
• Correções, da menos para a mais invasiva:
  1. Intermediário ausente em uma CA pública: corrija o pacote de certificados do próprio servidor para incluir a cadeia completa; isso não é um problema do lado do cliente.
  2. CA privada ou interna (comum atrás de proxies corporativos e em alguns runners de CI): instale essa CA no repositório de confiança que a ferramenta com falha realmente lê, já que o cacerts do Java, o pacote certifi do Python, o repositório próprio do Node e o repositório do sistema usado por curl/OpenSSL são todos independentes.
  3. Se a cadeia mudou de forma inesperada e há suspeita de interceptação, trate o caso como um evento de segurança: verifique o certificado por outro canal antes de prosseguir, e não desativando a verificação.
• Inseguro: curl -k/--insecure, verify=False do Python, NODE_TLS_REJECT_UNAUTHORIZED=0 ou git -c http.sslVerify=false. Cada um desativa justamente a verificação que detectaria um ataque machine-in-the-middle real, e nenhum deles deve virar solução permanente.

Armadilhas

• Corrigir o repositório de confiança de uma ferramenta (o do SO) enquanto outra (uma JVM, um venv do Python) mantém seu próprio pacote separado e continua falhando.
• Tratar uma interceptação temporária (um proxy corporativo que inspeciona TLS) como licença para desativar a verificação em todo lugar, em vez de confiar apenas na CA específica desse proxy.