Nao Em Nada Nao Ter Autoridade

O problema dos certificados que o navegador rejeita

Você já abriu um site e apareceu aquele aviso grande de que a conexão não é privada? Ou tentou configurar um serviço interno e a aplicação inteira parou de funcionar só porque o certificado não estava assinado por uma CA reconhecida? O problema é mais comum do que parece, e a solução raramente é "comprar um certificado". Na maioria das vezes, trata-se de entender como a cadeia de confiança funciona e por onde ela quebra na prática. Quando falamos sobre certificados digitais e autoridades de certificação, a expressão "não ter autoridade" se refere a qualquer certificado que o cliente (navegador, sistema operacional, aplicação) não reconhece como confiável. Isso acontece por várias razões distintas. Um certificado autoassinado simplesmente não tem nenhuma CA na cadeia. Um certificado emitido por uma CA gratuita, como Let's Encrypt, pode ser rejeitado em dispositivos mais antigos que não possuem os certificados raiz atualizados. Um certificado com nome divergente do domínio também gera rejeição, mas aí o problema é de configuaração, não de autoridade. O que eu vejo todo dia em ambiente de produção é gente confundindo esses cenários. Eles compram um certificado de uma autoridade qualquer, instalam, e quando o sistema continua rejeitando, não fazem a distinção básica entre "certificado mal instalado", "certificado com domínio errado" e "certificado de uma CA que simplesmente não está na lista de confiansa do dispositivo alvo".

A cadeia de confiança explicada sem teoria de livro

A cadeia funciona assim: o certificado do seu servidor (o leaf certificate) é assinado por uma CA intermediária, que por sua vez é assinada por uma CA raiz. O navegador ou o cliente verifica a assinatura de cada anel até chegar a um que ele já confia por padrão. Se um elo dessa corrente estiver faltando ou corrompido, a validação quebra. O erro mais frequente que eu encontro é a ausência do certificado intermediário no bundle. Muitas pessoas pegam apenas o certificado do domínio, colocam no servidor web e configuram. O navegador faz a requisição, vê o certificado do domínio, tenta encontrar a CA intermediária para validar a assinatura e não acha. O resultado é um erro de cadeia incompleta, não um erro de autoridade. A diferença é sutil mas muda completamente a solução. Eu tive um caso recente com um serviço interno rodando em Docker. O certificado estava perfeito, emitido por uma CA externa confiável, domínio correto. O problema era que o container não tinha os certificados intermediários empacotados no arquivo de bundle. A validação funcionava em máquinas Windows com os pacotes de atualização recentes, mas falhava em containers Alpine limpos que usam ca-certificates desatualizados. A correção foi criar um arquivo PEM contendo o certificado do domínio seguido pelo certificado intermediário da CA, nessa ordem, e apontar o servidor web para esse bundle. O tempo de debugging foi de cerca de 4 horas porque o log de erro do Nginx não dava muita informação — só o curl com a flag -v mostrou claramente onde a cadeia quebrava.

Como diagnosticar o problema na prática

A primeira ferramenta que eu uso é o próprio curl com verbose. Um comando como curl -v https://seudominio.com mostra passo a passo o que o cliente está recebendo e onde a validação falha. Se a saída mencionar "unable to get local issuer certificate", o problema é um certificado intermediário faltando. Se aparecer "hostname mismatch", o problema é o domínio no certificado não bater com a URL que você está acessando. Uma opção ainda mais direta é usar o openssl s_client. O comando openssl s_client -connect seudominio.com:443 -showcerts revela toda a cadeia de certificados que o servidor está enviando. Você vai ver quantos certificados existem na resposta. Se houver apenas um, provavelmente falta o intermediário. Se houver dois ou mais, a cadeia está tecnicamente completa, mas pode ainda haver um problema com a CA raiz não estar presente no repositório de confiança do cliente. Para sites públicos, ferramentas online como o SSL Labs (sslabs.com) ou o DigiCert SSL Checker fazem essa análise automática e mostram exatamente onde está o problema, incluindo scores de conformidade que vão além do básico.

Soluções para os cenários mais comuns

Certificado autoassinado para uso interno: Se o serviço é realmente interno e só você e sua equipe acessam, a solução mais prática é adicionar o certificado raiz autoassinado ao repositório de confiança de cada máquina cliente. No Linux, copie o certificado .crt para /usr/local/share/ca-certificates/ e rode sudo update-ca-certificates. No macOS, abra o Keychain Access, adicione o certificado e mude a configuração de confiança para "Always Trust". No Windows, importe peloMMC com o snap-in de certificados e coloque no repositório Trusted Root Certification Authorities. Isso resolve para aquelas máquinas, mas não escala bem se você tiver dezenas de dispositivos diferentes. Certificado intermediário faltando no servidor: Monte o bundle completo. No Nginx, o parâmetro ssl_certificate deve apontar para um arquivo que contém o certificado do domínio mais todos os intermediários, na ordem correta. O arquivo do Lets Encrypt costuma vir separado — o cert.pem é o certificado do domínio, o chain.pem são os intermediários. Junte os dois em um único arquivo. No Apache, use o directive SSLEertificateChainFile ou inclua os intermediários no mesmo arquivo do certficado principal. Para testes rápidos, você pode validar com openssl verify -CAfile bundle.pem certificado-do-dominio.crt. CA não reconhecida pelo cliente: Isso é mais chato porque envolve atualizações de sistema operacional. Certificados raiz expiram ou são revogados periodicamente. A CA raiz do DigiCert, por exemplo, passou por uma troca em 2021 que quebrou a validação em alguns dispositivos antigos que não receberam atualização de certificados raiz. A solução aqui é dupla: mantenha os sistemas atualizados e, para dispositivos embarcados ou sistemas legados que não recebem patches, considere emitir certificados a partir de uma CA com raiz amplamente suportada, como DigiCert, Sectigo ou GlobalSign.

Domínio divergente do certificado: Verifique o campo CN ou SAN do certificado com openssl x509 -in certificado.crt -text -noout | grep -A1 "Subject:". Se o domínio que você está acessando não estiver listado nem no CN nem nos SANs, o certificado simplesmente não serve para aquele host. Isso é comum quando se usa certificados wildcard (*.dominio.com) e depois se tenta acessar subdomínios que não cobrem, ou quando há configuração errada de virtual host.

O que muitos esquecem e custa caro depois

A renovação automática de certificados é o tipo de coisa que você configura uma vez e esquece, até o dia em que esquece. O Let's Encrypt renova a cada 90 dias, e o certbot cuida disso automaticamente se configurado corretamente. Mas em ambientes containerizados ou com múltiplos serviços, o certbot pode renovar o certificado no host e você precisa garantir que os containers ou serviços que fazem uso daquele certificado recarreguem a configuração. Um reload do Nginx ou um restart do serviço é suficiente. Sem isso, o certificado novo existe no disco mas nunca é carregado, e você gasta meia hora tentando entender por que o certificado ainda está expirado mesmo tendo renovado. Outro ponto que ninguém mentiona é a diferença entre certificados ECC e RSA em termos de compatibilidade. Certificados ECC oferecem o mesmo nível de segurança com chaves menores, o que significa menos bytes trafegados no handshake TLS. Mas dispositivos muito antigos, especialmente equipamentos de rede ou sistemas embarcados com firmwares desatualizados, podem não suportar curvas elípticas modernas. Se o seu público-alvo inclui esses dispositivos, fique com RSA. Se não, ECC é claramente superior em performance. Também vale mencionar que certificados DV (Domain Validation) são suficientes para a grande maioria dos casos. Certificados OV (Organization Validation) e EV (Extended Validation) existem, mas o EV em particular perdeu quase todo o valor prático — os navegadores pararam de exibir a barra verde com o nome da empresa há anos, e a única diferença real é que a CA faz uma verificação um pouco mais rigorosa da organização. Para serviços internos ou aplicações que consomem APIs, DV resolve e custa muito menos.

Alternativas quando o problema é infraestrutura legada

Se você está lidando com um sistema que simplesmente não aceita certificados de CA externas ou não consegue manter o repositório de confiança atualizado, existem alternativas. Uma delas é usar um proxy reverso com terminação TLS em um serviço que você controla, como um HAProxy ou Nginx rodando numa VM com os certificados configurados corretamente. Os sistemas legados se comunicam via HTTP interno, e a camada TLS fica concentrada no proxy. Isso isola o problema de certificados dos sistemas que não evoluem. Outra abordagem, mais drástica mas funcional, é criar uma CA interna com o OpenSSL ou com ferramentas como EasyRSA. Você gera sua própria raiz, distribui o certificado raiz para todos os clientes que precisam acessar os serviços, e emite certificados sob essa autoridade. Funciona perfeitamente para ambientes fechados. O downside é que você precisa gerenciar o ciclo de vida da CA raiz e garantir que ela não seja comprometida. Se alguém obter a chave privada da CA raiz, poderá emitir certificados para qualquer domínio e todos os clientes confiarão.

Checklist rápido antes de declarar que o problema está resolvido

Verifique a cadeia completa com openssl s_client e confirme que todos os certificados intermediários estão presentes. Valide o bundle com openssl verify. Confirme que o domínio ou SANs batem com a URL de acesso. Teste em pelo menos dois clientes diferentes — um navegador desktop e um celular, por exemplo — porque a lista de CAs confiáveis varia entre plataformas. Verifique a data de expiração com openssl x509 -enddate. E finalmente, configure monitoramento de expiração. Existem scripts simples que verificam a validade do certificado diariamente e mandam um alerta se faltarem menos de 30 dias. Isso evita aquele despertar às 3 da manhã quando o site cai por certificado vencido. O que eu vejo mais gente negligenciando é justamente esse último ponto. Configurar a renovação automática e esquecer é aceitável. Não monitorar a renovação e a expiração é pedir para ter dor de cabeça. Um certificado vencido é um dos problemas mais simples de resolver quando você percebe com antecedência, e um dos mais destrutivos quando você descobre tarde demais.