O que acontece quando a cadeia de confiança quebra
Um erro de confiança em certificados digitais aparece sempre da mesma forma prática: a conexão cai e você fica olhando para um popup ou log de erro sem saber exatamente qual elo da cadeia falhou. A mensagem de confiança quebrada pode significar várias coisas dependendo do contexto, e a maioria das pessoas assume que é apenas um certificado expirado. Raramente é só isso. A estrutura básica de qualquer validação de certificado segue a cadeia de confiança: seu certificado termina em uma autoridade certificadora (CA) raiz que está presente no repositório de confiança do sistema ou do navegador. Se qualquer elo dessa corrente estiver ausente, revogado ou incorretamente configurado, a validação falha.
Diagnóstico de mensagem de confiança quebrada em produção
No Windows, o erro mais comum é o código -2146762487 (0x800B0109), que indica que o certificado não está na cadeia de confiança confiável. No Linux com OpenSSL, você vê algo como "self-signed certificate" ou "unable to get local issuer certificate". No navegador Chrome, é aquele aviso vermelho de NET::ERR_CERT_AUTHORITY_INVALID. São a mesma doença com sintomas diferentes. O que a maioria dos administradores não percebe na primeira vez é que a mensagem de confiança quebrada frequentemente aparece porque o certificado intermediário não foi empacotado corretamente no arquivo .crt ou .pfx entregue pelo fornecedor. O certificado do domínio está correto, a CA raiz está presente no sistema, mas o intermediário que faz a ponte entre os dois simplesmente não está no bundle. O resultado é que o cliente tenta construir a cadeia, não encontra o elo intermediário e aborta.
Um caso específico que lembro bem: há dois anos, migrei um serviço de uma VM Windows Server 2019 para um container Docker com nginx. O certificado era de uma CA comercial válida, instalado corretamente no IIS da VM original. Configurei o nginx com o certificado completo, copiei o arquivo .pem, mudei a porta, e tudo funcionou perfeitamente até o dia em que um cliente relatou que o site não abria no celular deles usando Wi-Fi corporativo. O erro era exatamente esse: o certificado intermediário que eu tinha exportado do IIS vinha desordenado. O nginx exige que o arquivo de chaining tenha primeiro o certificado do domínio e em seguida o intermediário, nessa ordem exata. Eu tinha colado na ordem inversa. O Chrome no desktop aceitava porque o cache de certificados do Windows compensava, mas o iOS e muitos dispositivos Android validam a cadeia do zero. A correção foi simplesmente reordenar os certificados no bundle com um comando direto de cat, invertendo a ordem das seções PEM. Outro cenário que passa despercebido é a revogação. Um certificado pode ser perfeitamente válido em termos de data e cadeia, mas se o CRL (Certificate Revocation List) da CA intermediária mudou e o seu sistema não consegue acessar o URL de revogação, alguns clientes rígidos rejeitam a conexão. Isso é particularmente comum em ambientes corporativos com firewalls que bloqueiam requisições OCSP ou acesso a servidores CRL externos. A solução aqui não é instalar outro certificado, é garantir que o servidor possa baixar a lista de revogação ou configurar o nginx ou IIS para não validar revogação. Em muitos casos, desativar a validação OCSP no lado do servidor resolve imediatamente, já que a maioria dos navegadores trata falha de OCSP como soft-failure e continua a conexão.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Quando se trata de certificados auto-assinados em ambientes internos, a mensagem de confiança quebrada é esperada por design. O certificado não é emitido por uma CA que o cliente reconhece. A solução não é complicada: basta adicionar o certificado root à store de confiança do dispositivo ou do browser. No Windows, isso é feito abrindo o arquivo .cer pelo assistente de importação e colocando no repositório Trusted Root Certification Authorities. No Linux, copia-se o certificado para /usr/local/share/ca-certificates/ e roda-se update-ca-certificates. No Chrome, o caminho é diferente do sistema operacional; o Chrome usa o repositório do SO no Windows mas mantém sua própria store no macOS e Linux. Uma armadilha comum com certificados DNS SAN é achar que a mensagem de confiança quebrada está no certificado quando na verdade está no nome. Se o certificado foi emitido para api.example.com e você acessa por 10.0.0.5 ou staging.example.com, a validação de nome falha e o browser reporta erro de confiança. A mensagem é enganosa. O certificado é válido, a cadeia está intata, mas o hostname não corresponde. Verificar com openssl s_client -connect seunetwork.com:443 -servername seunetwork.com resolve isso em segundos e mostra exatamente qual campo SAN não bateu.
Para scripts automatizados que consomem APIs com TLS, o problema aparece como um erro de handshake. Curl lança o erro 60 ou 77 dependendo da versão, dependendo se é certificado auto-assinado ou chain incompleta. A flag --resolve ou CAINFO resolve, mas o ideal é corrigir a causa raiz em vez de desligar a verificação com -k. Desligar verificação em produção é prática ruim que gera problemas maiores depois. O procedimento prático para diagnosticar é rodar openssl s_client conectado ao seu serviço e observar a saída. A linha verify: retorna 0 se a cadeia estiver perfeita, qualquer outro número indica onde a cadeia quebrou. O valor 2 significa que a cadeia não pôde ser construída porque falta um intermediário. O valor 18 indica certificado auto-assinado. O valor 10 é revogação. Esses códigos são padronizados e economizam muito tempo de investigação.
Se você precisa de um bundle completo para resolver mensagem de confiança quebrada causada por intermediário faltante, a maneira mais direta é usar a cadeia fornecida pela própria CA. A maioria dos provedores entrega um arquivo chain.pem ou fullchain.pem separado do certificado do domínio. Nunca use apenas o cert.pem isoladamente em servidores de produção. O arquivo fullchain sempre contém o certificado do domínio seguido de todos os intermediários necessários na ordem correta. Em resumo, a mensagem de confiança quebrada é um sintoma, não um diagnóstico. A causa real pode ser intermediário ausente, ordem errada no bundle, revogação inacessível, hostname incompatível com SAN, certificado auto-assinado não instalado na store de confiança, ou simply uma CA raiz não reconhecida pelo sistema cliente. Diagnosticar corretamente evita reinstallar certificados à toa e economiza horas de debugging.
