Como Corrigir o Erro NET::ERR_CERT_AUTHORITY_INVALID

NET::ERR_CERT_AUTHORITY_INVALID é uma falha de handshake TLS ao nível do navegador que ocorre quando o certificado apresentado por um servidor web não pode ser rastreado até uma Autoridade de Certificação (CA) raiz confiável pelo repositório de confiança integrado do navegador. O navegador encerra a ligação antes de qualquer troca de dados, exibindo este erro para evitar a exposição a ataques man-in-the-middle (MITM), interceção de dados ou tráfego proveniente de um servidor falsificado.

Este não é um aviso cosmético. É uma falha de verificação criptográfica definitiva. O navegador inspecionou a cadeia de certificados, tentou validar cada ligação até uma raiz confiável e descobriu que a cadeia está quebrada, ausente ou criptograficamente inválida. Compreender exatamente onde essa cadeia se quebra é a diferença entre uma correção de cinco minutos e horas de diagnóstico incorreto.

O Que Realmente Desencadeia Este Erro

A maioria da documentação lista causas superficiais. O quadro real é mais matizado, e cada causa raiz exige um caminho de remediação diferente.

Certificados Auto-Assinados

Um certificado auto-assinado é aquele em que o emissor e o sujeito são idênticos — o servidor assinou o seu próprio certificado em vez de ter uma CA confiável a assiná-lo. Estes são padrão em ambientes de desenvolvimento local, servidores de staging internos e infraestrutura privada. Nenhum repositório de confiança de navegador público os reconhece, pelo que a validação da cadeia falha imediatamente.

Nuance crítica: Mesmo que adicione um certificado auto-assinado ao repositório de confiança do seu sistema operativo, alguns navegadores (notavelmente o Chrome em determinadas plataformas) utilizam o seu próprio repositório de certificados e continuarão a rejeitá-lo, a menos que seja explicitamente configurado.

Certificado SSL/TLS Expirado

Cada certificado contém um campo `notBefore` e `notAfter` codificado na sua estrutura X.509. Assim que o relógio do sistema ultrapassa o timestamp `notAfter`, o certificado é criptograficamente inválido, independentemente de como foi emitido. Os navegadores aplicam isto de forma rigorosa.

Caso extremo: Se o relógio do seu servidor avançar significativamente, um certificado que ainda é tecnicamente válido pode parecer expirado para o próprio servidor durante a negociação do handshake TLS, causando este erro do lado do servidor em vez do lado do cliente.

Cadeia de Certificados Incompleta (CA Intermédia em Falta)

Esta é a causa mais frequentemente mal diagnosticada em ambientes de produção. Uma CA raiz confiável não assina diretamente certificados de entidade final. Assina CAs intermédias, que por sua vez assinam o seu certificado. Quando instala um certificado SSL num servidor, deve instalar a cadeia completa: o seu certificado de entidade final mais todos os certificados intermédios concatenados por ordem.

Se o intermediário estiver ausente da resposta TLS do servidor, a maioria dos navegadores não consegue completar a verificação da cadeia até uma raiz confiável. O Firefox é um pouco mais tolerante aqui porque armazena em cache os intermediários de sessões anteriores (AIA fetching), mas o Chrome e o Edge falharão definitivamente.

Como verificar: Execute `openssl s_client -connect yourdomain.com:443 -showcerts` e inspecione se a cadeia completa é devolvida.

Nome Comum do Certificado ou SAN Incompatível

Se um certificado foi emitido para `www.example.com` mas o utilizador está a aceder a `example.com` (ou um subdomínio não coberto por um wildcard), o navegador apresentará um erro relacionado mas distinto. No entanto, em algumas configurações isto manifesta-se como um erro de autoridade inválida em vez de um erro de incompatibilidade de nome, particularmente com formatos de certificado mais antigos que não possuem Subject Alternative Names (SANs).

Desvio de Relógio do Lado do Cliente

Os certificados TLS são limitados no tempo. Se o relógio da máquina cliente estiver definido para uma data anterior ao campo `notBefore` do certificado ou posterior ao seu campo `notAfter`, o navegador irá rejeitá-lo. Isto é extremamente comum em máquinas virtuais, servidores recentemente aprovisionados ou máquinas que estiveram desligadas por períodos prolongados sem sincronização NTP.

Inspeção SSL por Software de Segurança

Firewalls corporativas, suites de segurança de endpoint e alguns produtos antivírus realizam inspeção SSL/TLS (também chamada interceção HTTPS). Terminam a ligação TLS no aparelho de segurança, inspecionam o texto simples e depois voltam a encriptá-lo usando um certificado gerado dinamicamente assinado pela própria CA do aparelho. Se essa CA do aparelho não estiver no repositório de confiança do navegador, todos os sites HTTPS irão desencadear este erro.

Repositório de Certificados Raiz Desatualizado

Em sistemas operativos mais antigos (Windows 7 sem atualizações, distribuições Linux legadas), o pacote de CA raiz do sistema pode não incluir certificados raiz mais recentes. O ISRG Root X1 do Let’s Encrypt, por exemplo, causou erros generalizados no Android 7 e versões anteriores e em sistemas Windows sem patches quando a assinatura cruzada DST Root CA X3 expirou em setembro de 2021.

Comparação de Causas Raiz

Correções Passo a Passo

Passo 1: Sincronizar a Data e Hora do Sistema

Esta é a correção mais rápida quando o erro aparece subitamente numa máquina que estava a funcionar anteriormente.

Windows:

1. Abra Definições > Hora e Idioma > Data e hora.
2. Ative Definir hora automaticamente e Definir fuso horário automaticamente.
3. Clique em Sincronizar agora em “Sincronizar o seu relógio.”
4. Se a sincronização automática falhar, abra a Linha de Comandos como Administrador e execute: `w32tm /resync /force`

macOS:

1. Abra Definições do Sistema > Geral > Data e Hora.
2. Ative Definir hora e data automaticamente e selecione um servidor NTP próximo (por exemplo, `time.apple.com`).
3. Se o problema persistir, execute no Terminal: `sudo sntp -sS time.apple.com`

Linux (servidor ou desktop):

“`bash

sudo timedatectl set-ntp true

sudo systemctl restart systemd-timesyncd

timedatectl status

“`

Após sincronizar, reinicie o navegador e tente novamente.

Passo 2: Limpar Cache do Navegador, Cookies e Certificados em Cache

Os navegadores armazenam em cache as políticas HSTS (HTTP Strict Transport Security) e dados de certificados. Uma entrada de cache desatualizada pode perpetuar um erro mesmo após a resolução do problema subjacente.

Google Chrome:

1. Navegue para `chrome://settings/clearBrowserData`.
2. Defina o intervalo de tempo para Todo o período.
3. Marque Cookies e outros dados do site e Imagens e ficheiros em cache.
4. Clique em Limpar dados.

Para limpar o cache específico de HSTS no Chrome, navegue para `chrome://net-internals/#hsts`, introduza o domínio em “Eliminar políticas de segurança do domínio” e clique em Eliminar.

Mozilla Firefox:

1. Abra Definições > Privacidade e Segurança.
2. Em Cookies e Dados do Site, clique em Limpar Dados.
3. Limpe também o Conteúdo Web em Cache.

Microsoft Edge:

1. Navegue para `edge://settings/clearBrowserData`.
2. Selecione Todo o período e limpe os dados em cache e cookies.

Passo 3: Identificar e Desativar a Inspeção SSL

Se estiver numa rede corporativa ou a utilizar um produto de segurança de endpoint, a inspeção SSL é o principal suspeito.

1. Clique no ícone de cadeado (ou ícone de aviso) na barra de endereços do navegador.
2. Inspecione os detalhes do certificado. Se o emissor for o seu fornecedor de antivírus (por exemplo, “Avast Root,” “Kaspersky Anti-Virus,” “ESET SSL Filter CA”) em vez de uma CA pública como DigiCert, Let’s Encrypt ou Sectigo, a inspeção SSL está ativa.
3. Nas definições do seu antivírus ou firewall, localize Análise HTTPS, Filtragem SSL ou Web Shield e desative-o.
4. Em alternativa, adicione o certificado CA raiz do aparelho ao repositório de confiança do seu navegador.

Não desative permanentemente o seu software de segurança. Reative-o após os testes ou configure-o para excluir domínios confiáveis específicos.

Passo 4: Verificar e Reparar a Cadeia de Certificados do Lado do Servidor (Administradores de Servidor)

Esta é a correção correta para sites de produção onde os visitantes estão a ver o erro.

Diagnosticar a cadeia:

“`bash

openssl s_client -connect yourdomain.com:443 -showcerts 2>/dev/null | openssl x509 -noout -text | grep -E "Issuer:|Subject:"

“`

Ou utilize a inspeção completa da cadeia:

“`bash

openssl s_client -connect yourdomain.com:443 -showcerts

“`

Conte os certificados devolvidos. Deve ver pelo menos dois (entidade final + intermediário). Se apenas um aparecer, o intermediário está em falta.

Correção no Apache (`httpd.conf` ou ficheiro de host virtual):

“`apache

SSLCertificateFile /etc/ssl/certs/yourdomain.crt

SSLCertificateKeyFile /etc/ssl/private/yourdomain.key

SSLCertificateChainFile /etc/ssl/certs/intermediate.crt

“`

Correção no Nginx (`nginx.conf` ou bloco de servidor):

O Nginx requer que a cadeia completa seja concatenada num único ficheiro:

“`bash

cat yourdomain.crt intermediate.crt > fullchain.pem

“`

Em seguida, referencie-o:

“`nginx

ssl_certificate /etc/ssl/certs/fullchain.pem;

ssl_certificate_key /etc/ssl/private/yourdomain.key;

“`

Após editar, teste sempre a configuração antes de reiniciar:

“`bash

Apache

apachectl configtest

Nginx

nginx -t

“`

Em seguida, recarregue o serviço:

“`bash

sudo systemctl reload apache2

or

sudo systemctl reload nginx

“`

Se estiver a executar um ambiente gerido, um VPS com cPanel fornece uma interface GUI em Gestor SSL/TLS onde pode colar o certificado, a chave privada e o pacote CA diretamente sem tocar manualmente nos ficheiros de configuração.

Passo 5: Renovar ou Substituir um Certificado Expirado

Se o certificado expirou, não existe solução alternativa do lado do cliente. O servidor deve apresentar um certificado válido.

Para Let’s Encrypt (Certbot):

“`bash

sudo certbot renew –dry-run

sudo certbot renew

sudo systemctl reload nginx # or apache2

“`

Para certificados geridos manualmente: Obtenha um novo certificado da sua CA, carregue-o através do seu painel de controlo e certifique-se de que a cadeia do novo certificado está completa. Se precisar de um certificado confiável para um domínio de produção, os Certificados SSL de uma CA reconhecida eliminam completamente o problema do certificado auto-assinado.

Automatizar renovações: Os certificados Let’s Encrypt expiram a cada 90 dias. Adicione um cron job ou utilize temporizadores systemd para automatizar a renovação:

“`bash

0 3 * * * /usr/bin/certbot renew –quiet –post-hook "systemctl reload nginx"

“`

Passo 6: Confiar num Certificado Auto-Assinado para Uso Interno

Se estiver a executar ferramentas internas, um servidor de desenvolvimento ou um serviço de rede privada onde a substituição do certificado não é viável, pode adicionar o certificado auto-assinado ao repositório de confiança do SO.

Windows:

1. Exporte o certificado do navegador (clique no aviso > Certificado > Detalhes > Copiar para Ficheiro).
2. Abra `certmgr.msc`.
3. Navegue para Autoridades de Certificação Raiz Confiáveis > Certificados.
4. Clique com o botão direito > Todas as Tarefas > Importar e importe o certificado.

macOS:

“`bash

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /path/to/cert.crt

“`

Linux (Debian/Ubuntu):

“`bash

sudo cp cert.crt /usr/local/share/ca-certificates/

sudo update-ca-certificates

“`

Importante: O Chrome no Linux e Windows utiliza o repositório de confiança do SO para a maioria dos fins, mas também mantém a sua própria base de dados NSS. Se o Chrome ainda rejeitar o certificado após atualizar o repositório do SO, importe-o diretamente via `chrome://settings/certificates`.

Passo 7: Atualizar o Navegador e o Sistema Operativo

Um navegador desatualizado pode não ter certificados CA raiz mais recentes ou pode não suportar as versões atuais do protocolo TLS (TLS 1.2 mínimo é agora obrigatório; TLS 1.3 é preferido).

Chrome: Navegue para `chrome://settings/help`. O Chrome atualiza-se automaticamente; se houver uma atualização pendente, será instalada aqui.

Firefox: Navegue para Ajuda > Sobre o Firefox. O Firefox verificará e aplicará atualizações.

Sistema Operativo: No Windows, certifique-se de que o Windows Update está atualizado. Em servidores Linux, execute:

“`bash

sudo apt update && sudo apt upgrade ca-certificates openssl

“`

Isto é particularmente importante para servidores que executam distribuições mais antigas onde o pacote CA (`ca-certificates`) não foi atualizado para incluir CAs raiz mais recentes.

Passo 8: Reiniciar a Pilha de Rede e Limpar DNS

Configurações incorretas ao nível da rede, caches DNS corrompidas ou entradas Winsock desatualizadas podem ocasionalmente contribuir para falhas na negociação TLS.

Windows (execute a Linha de Comandos como Administrador):

“`cmd

netsh int ip reset

netsh winsock reset

ipconfig /release

ipconfig /renew

ipconfig /flushdns

“`

Reinicie a máquina após executar estes comandos.

macOS:

“`bash

sudo dscacheutil -flushcache

sudo killall -HUP mDNSResponder

“`

Linux:

“`bash

sudo systemd-resolve –flush-caches

or for systems using nscd:

sudo service nscd restart

“`

Passo 9: Ignorar o Aviso (Apenas para Testes)

Esta é estritamente uma ferramenta de diagnóstico, não uma solução. Utilize-a apenas para confirmar que o erro está relacionado com o certificado e não com um problema de rede ou aplicação, ou ao aceder a um servidor interno conhecido e seguro durante o desenvolvimento.

Chrome: Clique em Avançado na página de erro e depois em Continuar para [domínio] (não seguro).

Firefox: Clique em Avançado e depois em Aceitar o Risco e Continuar.

Nunca ignore este aviso em sites que processam autenticação, pagamentos ou dados pessoais. O aviso existe porque a ligação é genuinamente não verificada.

Verificar a Correção

Após aplicar qualquer alteração do lado do servidor, valide o resultado utilizando estas ferramentas antes de declarar o problema resolvido:

• SSL Labs SSL Test (`ssllabs.com/ssltest/`): Fornece uma análise completa da cadeia, classificação de suporte de protocolo e identifica fraquezas específicas de configuração.
• `openssl s_client`: Verificação por linha de comandos que mostra exatamente o que o servidor está a apresentar durante o handshake TLS.
• `curl -vI https://yourdomain.com`: Verificação rápida que mostra detalhes do handshake TLS e resultado da validação do certificado.
• `whatsmychaincert.com`: Diagnostica especificamente certificados intermédios em falta.

Escolher a Infraestrutura de Alojamento Correta para Prevenir Recorrências

Muitos erros de certificado resultam de limitações de infraestrutura em vez de erros do administrador. Os ambientes de alojamento partilhado por vezes restringem a forma como as cadeias de certificados são configuradas ou limitam o acesso aos ficheiros de configuração do servidor web. Se estiver a encontrar repetidamente problemas de cadeia ou renovação, migrar para um ambiente de Alojamento VPS dá-lhe controlo total sobre a sua pilha TLS — incluindo a capacidade de configurar o Nginx ou Apache diretamente, automatizar renovações Certbot e instalar pacotes CA personalizados.

Para cargas de trabalho de alto tráfego ou sensíveis à conformidade onde a gestão de certificados é crítica, os Servidores Dedicados eliminam as variáveis multi-inquilino que podem complicar a configuração SSL. Se estiver a gerir múltiplos domínios ou subdomínios, um Painel de Controlo VPS simplifica a implementação de certificados em todos eles a partir de uma única interface.

Matriz de Decisão: Qual Correção se Aplica à Sua Situação

Lista de Verificação de Pontos-Chave Práticos

• Confirme se o erro é do lado do cliente (relógio, cache, inspeção SSL) ou do lado do servidor (certificado expirado, intermediário em falta) antes de tomar qualquer ação.
• Execute `openssl s_client -connect domain:443 -showcerts` como primeiro passo de diagnóstico para qualquer investigação do lado do servidor.
• Concatene sempre a cadeia de certificados completa (entidade final + todos os intermediários) na configuração do seu servidor web.
• Automatize a renovação de certificados com cron jobs Certbot ou equivalente — a renovação manual é um caminho garantido para futuras interrupções.
• Após qualquer alteração de certificado, valide com o SSL Labs antes de fechar o incidente.
• Nunca desative permanentemente a análise SSL do antivírus; em vez disso, configure exclusões ou instale corretamente o certificado CA do proxy.
• Em servidores Linux, mantenha os pacotes `ca-certificates` e `openssl` atualizados para garantir que o repositório raiz reflete as CAs confiáveis atuais.
• Utilize `chrome://net-internals/#hsts` para limpar entradas de cache HSTS quando o certificado de um domínio foi legitimamente alterado e o Chrome ainda se recusa a ligar.

Perguntas Frequentes

Qual é a diferença entre NET::ERR_CERT_AUTHORITY_INVALID e NET::ERR_CERT_COMMON_NAME_INVALID?

`ERR_CERT_AUTHORITY_INVALID` significa que o emissor do certificado não é confiável — a cadeia não pode ser verificada. `ERR_CERT_COMMON_NAME_INVALID` significa que o certificado é de uma CA confiável mas foi emitido para um domínio diferente do que está a ser acedido. Requerem correções diferentes: o primeiro requer um novo certificado de uma CA confiável ou reparação da cadeia; o segundo requer um certificado reemitido com os Subject Alternative Names corretos.

Pode o NET::ERR_CERT_AUTHORITY_INVALID aparecer mesmo com um certificado SSL válido e pago?

Sim. Um certificado pago de uma CA confiável ainda irá desencadear este erro se o certificado intermediário não estiver incluído na resposta TLS do servidor. O navegador nem sempre consegue obter automaticamente os intermediários em falta (o AIA fetching é pouco fiável), pelo que a cadeia deve ser explicitamente configurada no servidor.

Por que este erro aparece apenas no Chrome mas não no Firefox?

O Firefox mantém o seu próprio repositório de confiança de certificados e também armazena em cache os certificados intermédios de ligações bem-sucedidas anteriores (um mecanismo chamado AIA fetching com cache). O Chrome depende mais estritamente do repositório de confiança do SO e da cadeia apresentada pelo servidor. Um intermediário em falta que o Firefox tenha armazenado em cache de uma sessão anterior ainda causará falha no Chrome.

É seguro clicar em “Continuar mesmo assim” no aviso NET::ERR_CERT_AUTHORITY_INVALID?

Apenas em cenários controlados: aceder a um servidor interno conhecido, um ambiente de desenvolvimento local ou um servidor de staging que administra. Em qualquer site público — especialmente aqueles que requerem credenciais de login, informações de pagamento ou dados pessoais — continuar é genuinamente perigoso. A ligação não está encriptada do ponto de vista da confiança, o que significa que qualquer intercetor no caminho da rede pode ler ou modificar o tráfego.

Como posso evitar que este erro recorra no meu servidor de produção?

Automatize a renovação de certificados (Certbot com um cron job ou temporizador systemd), monitorize a expiração de certificados com uma ferramenta externa (UptimeRobot, Zabbix ou `ssl-cert-check`), implemente sempre a cadeia de certificados completa e mantenha a sincronização NTP do seu servidor ativa. Para ambientes onde a gestão manual é propensa a erros, considere uma plataforma de alojamento com gestão integrada de certificados — um VPS com cPanel trata das renovações AutoSSL automaticamente em todos os domínios alojados.