Erro Sua Conexão Não É Privada (SSL): Como Diagnosticar e Resolver
Resolva o erro NET::ERR_CERT_AUTHORITY_INVALID e variantes SSL no navegador identificando a causa real — certificado, cadeia, data ou DNS.
O aviso “Sua conexão não é privada” no Chrome (ou “Aviso: risco potencial de segurança à frente” no Firefox) é uma das telas mais ambíguas da web moderna. Por trás de uma única mensagem amigável, o navegador esconde mais de quinze códigos de erro distintos — cada um apontando pra uma causa raiz diferente. Tratar todos como o mesmo problema leva a tentativas erradas: renovar um certificado que está válido, mexer no DNS quando o problema é relógio, ou pior, instruir o usuário final a clicar em “Avançar” e expor a conexão.
Este guia é pra quem opera um servidor próprio (VPS ou bare-metal) e precisa identificar rapidamente qual é o problema real, separar o que é responsabilidade do servidor do que é do cliente, e aplicar a correção certa. O processo completo leva entre 10 e 20 minutos, dependendo da causa.
A premissa fundamental: o erro SSL é sempre específico. Antes de tocar em qualquer configuração, você precisa ler o código exato que o navegador mostra e decidir o caminho de diagnóstico.
Pré-requisitos
Acesso SSH ao servidor (sudo ou root), navegador atualizado (Chrome 117+ ou Firefox 120+) e ferramentas de linha de comando openssl, curl e dig instaladas. Em Ubuntu/Debian: sudo apt install -y openssl curl dnsutils. Conhecimento básico de como o seu servidor web está configurado (nginx, Apache ou Caddy).
443 /etc/letsencrypt/live/dominio/ fullchain.pem Identifique o código de erro exato
Antes de mexer em qualquer coisa, abra a página do erro no navegador e clique em “Avançado” (Chrome) ou “Detalhes técnicos” (Firefox). Você vai ver um código no formato NET::ERR_CERT_* ou SEC_ERROR_*. Esse código é o ponto de partida — cada um exige tratamento diferente.
A tabela abaixo cobre os mais comuns:
| Código | Causa provável | Onde corrigir |
|---|---|---|
NET::ERR_CERT_AUTHORITY_INVALID | CA não confiável ou cadeia incompleta | Servidor |
NET::ERR_CERT_DATE_INVALID | Certificado expirado ou relógio errado | Servidor ou cliente |
NET::ERR_CERT_COMMON_NAME_INVALID | Certificado pra outro domínio | Servidor |
NET::ERR_CERT_REVOKED | Certificado revogado pela CA | Servidor (reemitir) |
NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM | Algoritmo SHA-1 obsoleto | Servidor (reemitir SHA-256+) |
SSL_ERROR_BAD_CERT_DOMAIN | Domínio acessado não bate com SAN | Servidor |
NET::ERR_SSL_PROTOCOL_ERROR | TLS handshake falhou (versão/cipher) | Servidor |
Anote o código exato do erro e o domínio (incluindo subdomínio) onde aparece. A diferença entre www.site.com.br e site.com.br é crítica — um certificado emitido só pra um não cobre o outro automaticamente.
Teste em outro dispositivo na mesma rede e em uma rede diferente (4G do celular, por exemplo). Se o erro aparece em todos, é problema de servidor. Se aparece só em um, é local.
Diagnostique do lado do servidor
Use openssl s_client pra ver exatamente o que o servidor está apresentando ao navegador. Esse comando é o equivalente técnico de “abrir a página” — sem cache, sem extensões, sem ambiguidade.
Conecte ao seu domínio e capture a cadeia completa:
openssl s_client -connect dominio.com.br:443 \
-servername dominio.com.br \
-showcerts < /dev/nullA flag -servername é obrigatória — sem ela, servidores com múltiplos sites (SNI) podem entregar o certificado errado. A saída lista cada certificado servido entre -----BEGIN CERTIFICATE----- e -----END CERTIFICATE-----.
Verifique quantos certificados aparecem. Em uma configuração saudável você vê pelo menos 2: o leaf (do seu domínio) e o intermediário (da CA). Se aparecer só 1, a cadeia está incompleta — essa é a causa mais comum de NET::ERR_CERT_AUTHORITY_INVALID em servidores que “funcionavam até semana passada”.
Extraia data de validade e domínios cobertos:
echo | openssl s_client -connect dominio.com.br:443 \
-servername dominio.com.br 2>/dev/null | \
openssl x509 -noout -dates -subject -ext subjectAltNameVocê deve ver notBefore e notAfter (validade), o subject (domínio principal) e a lista de SAN (Subject Alternative Names — todos os domínios que o cert cobre).
Não tente renovar um certificado antes de confirmar que o problema é validade. Renovar um certificado que está válido mas com cadeia incompleta não resolve nada — você só vai trocar um leaf válido por outro leaf válido, mantendo o problema real.
Corrija problemas de cadeia incompleta
Cadeia incompleta é o erro de configuração mais comum em servidores Linux. Você gerou o certificado, copiou pro nginx, e tudo parece OK — mas o servidor está servindo só o leaf, sem o intermediário.
Em servidores nginx com Let’s Encrypt, a diretiva ssl_certificate deve apontar pra fullchain.pem, não pra cert.pem:
ssl_certificate /etc/letsencrypt/live/dominio.com.br/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/dominio.com.br/privkey.pem;O fullchain.pem é a concatenação do leaf + intermediário(s) na ordem correta. O cert.pem contém só o leaf — usar ele quebra clientes que não cacheiam o intermediário (boa parte dos Android antigos, sistemas embarcados, alguns sistemas operacionais corporativos).
Recarregue a configuração sem reiniciar:
sudo nginx -t && sudo systemctl reload nginxO nginx -t valida a sintaxe antes do reload — se falhar, sua configuração antiga continua rodando.
Em Apache, a diretiva equivalente é SSLCertificateFile, e desde a versão 2.4.8 ela aceita o fullchain. Em versões mais antigas você precisa de SSLCertificateChainFile apontando separadamente pro intermediário. Confira sua versão com apache2 -v (Debian/Ubuntu) ou httpd -v (RHEL/CentOS).
Corrija problemas de data e relógio
Se o código é NET::ERR_CERT_DATE_INVALID, há duas possibilidades: o certificado realmente expirou (servidor) ou o relógio do cliente está errado (local). Diferenciar é direto.
No servidor, verifique a hora atual e o serviço NTP:
timedatectl statusProcure por System clock synchronized: yes e NTP service: active. Se algum estiver no ou inactive:
sudo timedatectl set-ntp true
sudo systemctl restart systemd-timesyncdServidores virtuais que ficaram suspensos por muito tempo (snapshot restaurado, migração entre nodes) frequentemente acordam com relógio defasado — o certificado válido fica aparentemente expirado até o NTP sincronizar.
Compare a data do servidor com a validade do certificado:
date -u
echo | openssl s_client -connect dominio.com.br:443 \
-servername dominio.com.br 2>/dev/null | \
openssl x509 -noout -enddateSe a data atual for posterior ao notAfter, o certificado expirou — renove. Se for anterior ao notBefore, o certificado foi emitido pro futuro (raro, geralmente erro de timezone na hora da emissão).
Verifique se a correção funcionou
Depois de aplicar o fix, valide em três camadas — servidor, cadeia pública e navegador real.
Limpe o cache do navegador e teste em janela anônima. Cache de certificados é agressivo: o Chrome pode segurar um certificado antigo por até 24 horas em alguns casos. Janela anônima ignora boa parte desse cache.
Rode um teste externo via SSL Labs:
curl -sI https://api.ssllabs.com/api/v3/analyze?host=dominio.com.brOu abra https://www.ssllabs.com/ssltest/analyze.html?d=dominio.com.br no navegador. Você quer nota A ou A+. Notas B/C indicam problemas adicionais (protocolos fracos, ciphers obsoletos) que valem corrigir mesmo que o erro principal já tenha sumido.
Validar só no Chrome do seu desktop não é suficiente. Teste em pelo menos: Firefox (store de CA independente), Safari iOS (validação mais rigorosa) e curl da linha de comando (curl -v https://dominio.com.br). Se os três funcionarem sem warning, sua configuração está sólida.
Resolução de problemas frequentes
Erro só aparece em www mas não na raiz (ou vice-versa)
Seu certificado cobre só um dos dois. Reemita incluindo ambos os nomes. Com certbot:
sudo certbot --nginx -d dominio.com.br -d www.dominio.com.brO -d aceita múltiplos domínios numa única solicitação — eles vão pro mesmo certificado via SAN.
Erro depois de instalar antivírus ou proxy corporativo
Antivírus que fazem inspeção TLS (Kaspersky, BitDefender, ESET) instalam uma CA própria na máquina e reassinam todo tráfego HTTPS. Se essa CA não estiver no trust store do navegador, todo site quebra. Solução: desabilitar inspeção SSL no antivírus ou aceitar a CA dele manualmente. Em redes corporativas com proxy (Zscaler, Forcepoint), o time de TI precisa distribuir a CA da empresa via política de grupo.
Renovação automática parou de funcionar
Verifique o cron do certbot e os logs:
sudo systemctl status certbot.timer
sudo journalctl -u certbot --since "30 days ago"Causas comuns: porta 80 bloqueada no firewall (challenge HTTP-01 falha), DNS apontando pra IP errado depois de migração, ou rate limit do Let’s Encrypt (5 falhas por hora pelo mesmo domínio).
Próximos passos
Depois de resolver o erro imediato, vale endurecer a configuração TLS pra evitar recorrência. Considere habilitar HSTS (HTTP Strict Transport Security) com Strict-Transport-Security: max-age=31536000; includeSubDomains — isso força o navegador a usar HTTPS por um ano e elimina ataques de downgrade. Monitore expiração de certificados com ferramentas como Uptime Kuma ou um cron simples que dispara alerta 14 dias antes do notAfter. Para sites com tráfego sério, habilite OCSP stapling (ssl_stapling on no nginx) — reduz latência da primeira conexão e diminui dependência das CAs.
Se você está colocando isso em produção, uma VPS Hostini já vem com certbot pré-instalado e renovação automática configurada — você só aponta o DNS e roda o comando de emissão.
Perguntas frequentes
Por que o erro aparece só em alguns navegadores e em outros não?
Cada navegador mantém sua própria lista de autoridades certificadoras raiz confiáveis. Chrome e Edge usam a store do sistema operacional, Firefox tem store própria. Se o certificado foi emitido por uma CA que o Firefox conhece mas o Windows não, só o Chrome vai reclamar. Também influencia: política de revogação (Chrome respeita CRLite, Firefox usa OCSP) e suporte a algoritmos mais antigos.
O cadeado verde no Chrome desapareceu mas o site funciona — o certificado está válido?
Não necessariamente. O Chrome 117+ removeu o ícone de cadeado da UI por padrão e mostra apenas um ícone neutro de configurações. Clique no ícone e veja Conexão é segura para confirmar. Se aparecer Não segura ou um triângulo amarelo, há problema real — geralmente conteúdo misto (HTTPS carregando recurso HTTP) ou certificado vencendo em menos de 7 dias.
NET::ERR_CERT_AUTHORITY_INVALID em servidor com Let's Encrypt funcionando há meses — o que mudou?
Quase sempre é cadeia intermediária incompleta após renovação. Let's Encrypt mudou a raiz cruzada (ISRG Root X1 vs DST Root CA X3) em 2024, e configurações antigas que serviam só o leaf sem o intermediário R3 quebraram em clientes Android antigos e alguns sistemas. Sirva a fullchain.pem (não o cert.pem) na diretiva ssl_certificate.
O erro aparece em uma máquina específica da rede e em mais nenhuma — é problema do servidor?
Não. Se uma única máquina vê o erro enquanto as outras na mesma rede acessam normal, o problema é local: relógio fora de sincronia, antivírus interceptando TLS (Kaspersky, BitDefender, ESET fazem isso), proxy corporativo com CA própria não instalada, ou extensão de navegador interferindo. Comece pelo relógio.
Como verifico se a cadeia de certificados está completa antes de subir pra produção?
Use openssl s_client -connect dominio.com:443 -servername dominio.com -showcerts. A saída lista todos os certificados servidos. Você deve ver o leaf, o intermediário e idealmente a raiz. Se aparecer só 1 certificado, a cadeia está incompleta. Ferramentas como SSL Labs (ssllabs.com/ssltest) e testssl.sh dão diagnóstico mais visual e detectam outros problemas (protocolos fracos, ciphers obsoletos).
Posso ignorar o aviso e continuar — é seguro?
Depende da causa. Se for o seu próprio servidor de testes com certificado autoassinado, sim. Se for um site público que você não controla, não. O aviso pode indicar interceptação ativa por atacante (MITM em Wi-Fi público), CA comprometida ou phishing. Nunca clique em Continuar para sites onde você vai digitar senha, cartão ou dados sensíveis.