ERR_CERT_AUTHORITY_INVALID: como corrigir (Chrome, Android)

O que é NET::ERR_CERT_AUTHORITY_INVALID?

NET::ERR_CERT_AUTHORITY_INVALID significa que seu navegador não confia em quem emitiu o certificado do site. O Chrome mostra “Sua conexão não é particular” e, em Avançadas, diz que o servidor “não conseguiu provar que é example.com” porque o certificado de segurança dele não é confiável, o que “pode ser causado por uma configuração incorreta ou por um invasor que tenha interceptado sua conexão”. O Chromium o lista como o erro -202 (net_error_list.h).

A conexão foi estabelecida, o servidor enviou o certificado e o navegador não conseguiu ligá-lo a uma autoridade certificadora (CA) em que confia. As próprias anotações do Chromium dão três motivos: um invasor trocou o certificado, o site usa uma CA que o navegador não conhece ou o certificado é autoassinado.

Se um certificado tem vários problemas, o Chrome mostra só o mais grave, e um emissor não confiável pesa mais que um nome errado ou uma data vencida. Por isso um certificado autoassinado que também expirou mostra este código, e não ERR_CERT_DATE_INVALID.

Como o ERR_CERT_AUTHORITY_INVALID aparece em cada navegador

Cada navegador diz isso de um jeito. Procure estas mensagens:

Como funciona a confiança do certificado SSL (cadeia de confiança)

Todo certificado faz parte de uma cadeia de confiança que termina em um certificado raiz de uma autoridade certificadora em que o navegador já confia.

Ao se conectar, o servidor envia o próprio certificado e um ou mais intermediários. O navegador verifica se o certificado do site foi assinado pelo intermediário, e o intermediário por uma raiz da sua lista. O Chrome não usa mais a lista do seu sistema operacional para isso: ele tem a própria, a Chrome Root Store, no Windows e no macOS desde o Chrome 108 e no Android desde o Chrome 115 (não no iPhone e no iPad, onde a lista da Apple é obrigatória). Essa lista tem cerca de 100 raízes e é atualizada em segundo plano (Chrome Root Store). No Windows e no macOS, o Edge traz a lista da Microsoft; o Firefox, a da Mozilla; e todos também confiam nas raízes que você ou sua empresa adicionam ao computador.

Se algum elo estiver faltando ou for desconhecido, você recebe este erro (mais em o que é uma cadeia de certificados SSL). A cadeia tem quatro partes:

• CA raiz — autoassinada e incluída na lista de raízes do navegador
• CA intermediária — assinada pela raiz; o servidor precisa enviá-la. O Chrome baixa uma que esteja faltando a partir do endereço no certificado, mas o curl, os apps e muitos outros clientes não conseguem
• Certificado do site — assinado pelo intermediário, para os nomes da sua lista de Nomes Alternativos do Assunto
• Validação — o navegador percorre o caminho do certificado do site até uma raiz confiável; todas as assinaturas precisam conferir

O que causa NET::ERR_CERT_AUTHORITY_INVALID?

Onde você vê o erro restringe a causa: um site significa que o problema quase sempre é o certificado dele. Todos os sites HTTPS significa que é seu dispositivo ou sua rede.

Correções para visitantes (lado do cliente)

Se você vê o erro em um site que não administra, tente estas correções em ordem. Nunca digite uma senha ou um número de cartão em uma página que mostra este aviso.

Correção 1: entre no Wi-Fi ou tente outra rede

O Wi-Fi de hotéis, aeroportos e cafés costuma interceptar suas primeiras conexões para mostrar uma página de login, e então um site HTTPS recebe o certificado da rede em vez do próprio. A ajuda do Chrome diz que essas redes exigem login e que acessar uma página com http:// abre a página de login; o Chrome também pode mostrar a página “Conectar ao Wi-Fi” em vez deste erro. Aceite o login e recarregue.

Redes de empresas e escolas também podem inspecionar o HTTPS com um certificado próprio. Se o erro some nos dados móveis, pergunte à equipe de TI da rede: os dispositivos gerenciados por eles normalmente têm a raiz deles instalada, e o seu pode não ter.

Correção 2: verifique a verificação HTTPS do antivírus

Antivírus como Kaspersky, Avast, ESET e Bitdefender podem verificar o HTTPS descriptografando-o com um certificado próprio e criptografando de novo. Se o navegador não confia no certificado raiz deles, ou o recurso quebra após uma atualização, todos os sites HTTPS mostram este erro de uma vez.

Para testar, pause só o recurso de verificação HTTPS ou da web e recarregue. Se o erro desaparecer, repare ou atualize o antivírus para que ele reinstale o certificado, ou deixe a verificação HTTPS desativada.

Correção 3: atualize o navegador e o sistema operacional

Navegadores e sistemas operacionais atualizam suas listas de raízes com regularidade (o Chrome por atualizações de componentes em segundo plano), e sistemas antigos não têm as raízes mais novas. Versões do Android anteriores à 7.1.1, por exemplo, não confiam na ISRG Root X1, então sites da Let's Encrypt falham ali nos navegadores e apps que dependem da lista do sistema.

Atualize primeiro o navegador: Chrome e Edge trazem as próprias listas de raízes no Windows e no macOS, e o Chrome também no Android a partir da versão 115. Depois atualize o sistema operacional.

Correção 4: verifique a data e a hora

Um relógio errado por meses ou anos faz os certificados parecerem ainda não válidos ou expirados. O Chrome costuma mostrar outro aviso para isso (“Seu relógio está atrasado” ou ERR_CERT_DATE_INVALID), mas um relógio muito errado após a pilha CMOS acabar ou depois de restaurar uma máquina virtual também pode quebrar a verificação de confiança. Descartar isso leva dez segundos.

Windows: Configurações → Hora e idioma → Data e hora → ative Definir horário automaticamente. macOS: Ajustes do Sistema → Geral → Data e Hora → Definir data e hora automaticamente. Android: Configurações → Sistema → Data e hora → Definir hora automaticamente (no Android 16 o nome é Data e hora automáticas).

Correção 5: tente o modo anônimo e reinicie o navegador

Uma janela anônima (Ctrl+Shift+N no Chrome e no Edge, Ctrl+Shift+P para uma janela privativa no Firefox) funciona sem suas extensões, a menos que você as tenha permitido. Extensões de VPN e proxy podem rotear seu tráfego por um servidor que apresenta o próprio certificado; se o site funciona no modo anônimo, desative as extensões em chrome://extensions e reative uma de cada vez.

Se o site acabou de corrigir o certificado, feche todas as janelas do navegador e abra de novo, para que ele verifique o novo certificado do zero.

Correção 6: no Android

O Android acrescenta algumas verificações próprias:

• Defina a data e a hora automaticamente: Configurações → Sistema → Data e hora.
• Atualize o Chrome e o Android System WebView na Play Store. Apps que mostram páginas da web por meio do WebView verificam os certificados na lista de raízes do próprio Android, então uma versão antiga do Android ainda pode falhar ali.
• Desative apps de VPN, bloqueio de anúncios ou “navegação segura” que filtram o HTTPS; eles mostram um ícone de chave ou de VPN na barra de status.
• Entre no Wi-Fi: redes públicas mostram o erro até você aceitar a página de login.
• No Android anterior à 7.1.1, a raiz da Let's Encrypt não está na lista do sistema, então apps e navegadores que dependem dela não conseguem verificar esses sites. Um navegador que traga a própria lista de raízes é a única solução.

Correções para proprietários de sites (lado do servidor)

Se visitantes relatam NET::ERR_CERT_AUTHORITY_INVALID no seu site, o certificado que você serve normalmente não se liga a uma raiz pública. Verifique primeiro com o SSL Checker e corrija o que ele encontrar. Se ele mostrar um certificado diferente do que você instalou, confirme com o DNS Lookup que o domínio aponta para o servidor que você pensa e, com o HTTP Header Checker, qual servidor responde.

Correção 1: instale um certificado de uma CA confiável

Um certificado autoassinado, ou de uma CA própria, nunca será confiável para os navegadores dos visitantes: quem assinou não está em nenhuma lista pública de raízes.

Instale um certificado de uma CA publicamente confiável. A Let's Encrypt emite certificados gratuitos e automatizados em que todos os principais navegadores confiam; DigiCert, Sectigo e GlobalSign vendem certificados com validação de organização e suporte.

# Install Let's Encrypt certificate with Certbot (Nginx)
sudo certbot --nginx -d example.com -d www.example.com

# Install Let's Encrypt certificate with Certbot (Apache)
sudo certbot --apache -d example.com -d www.example.com

# Verify the installed certificate
sudo certbot certificates

Correção 2: envie a cadeia completa de certificados

Seu certificado pode ser perfeitamente válido e o servidor esquecer de enviar o intermediário. O Chrome costuma disfarçar isso baixando o intermediário que falta por conta própria, então o site funciona no Chrome e falha no curl, em apps, em callbacks de pagamento e em alguns celulares.

Passe o site pelo SSL Checker do DNS Robot: ele mostra a cadeia que seu servidor envia e se Mozilla, Chrome, Apple e Microsoft confiam nela. Ou verifique pelo terminal:

# List each certificate the server sends (s: subject, i: issuer)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E ' [si]:'

# letsencrypt.org on 26 Oct 2026, a complete chain:
#  0 s:CN=letsencrypt.org
#    i:C=US, O=Let's Encrypt, CN=YE2
#  1 s:C=US, O=Let's Encrypt, CN=YE2
#    i:C=US, O=ISRG, CN=Root YE
#  2 s:C=US, O=ISRG, CN=Root YE
#    i:C=US, O=Internet Security Research Group, CN=ISRG Root X2
#  3 s:C=US, O=Internet Security Research Group, CN=ISRG Root X2
#    i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
# Only certificate 0 listed = the intermediate is missing.

# nginx: point ssl_certificate at the full chain, not the leaf alone
ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

# Apache 2.4.8+
SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

Correção 3: renove um certificado expirado

Um certificado expirado de uma CA confiável mostra ERR_CERT_DATE_INVALID, não este erro. Você só verá ERR_CERT_AUTHORITY_INVALID se a cadeia também não for confiável, porque o Chrome relata o problema mais grave. De qualquer forma, verifique as datas e renove:

# Check the certificate's dates
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates
# notBefore=Sep 30 12:00:00 2026 GMT
# notAfter=Dec 29 11:59:59 2026 GMT

# Renew now with Certbot, then reload the web server
sudo certbot renew --force-renewal
sudo systemctl reload nginx    # or apache2

Correção 4: cubra todos os nomes que os visitantes usam

Um certificado confiável que não lista o nome da barra de endereços mostra ERR_CERT_COMMON_NAME_INVALID. Ele só vira este erro quando o certificado também não é confiável, então corrija primeiro a confiança e depois os nomes.

Os navegadores verificam apenas a lista de Nomes Alternativos do Assunto (Subject Alternative Name), não o antigo Common Name. Um curinga (*.example.com) cobre um nível de subdomínios, mas não o próprio example.com, então liste os dois ao solicitar. O SSL Checker mostra a lista completa de nomes de um certificado.

Correção 5: usando uma CA privada ou da empresa

Sites internos costumam usar uma CA da empresa de propósito. Isso só funciona em dispositivos onde o certificado raiz da empresa está instalado, e Chrome e Edge confiam em uma raiz adicionada ao Windows ou ao macOS (Chrome Root Store FAQ). Distribua-a com Política de Grupo ou sua ferramenta de gerenciamento de dispositivos, ou adicione manualmente:

# Windows (Command Prompt as Administrator): trust for all users
certutil -addstore -f Root company-root.crt

# macOS: trust in the System keychain
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain company-root.crt

ERR_CERT_AUTHORITY_INVALID no localhost (desenvolvedores)

Um servidor HTTPS local com certificado autoassinado mostra este erro por design. Em vez de clicar para continuar, torne o certificado confiável na sua própria máquina:

• mkcert — mkcert -install cria uma CA local e a adiciona ao repositório de confiança do sistema (e ao do Firefox, depois de instalar o certutil do NSS); então mkcert localhost 127.0.0.1 ::1 gera um certificado em que Chrome, Edge e Firefox confiam
• Next.js — next dev --experimental-https cria para você um certificado confiável localmente com o mkcert
• Vite — @vitejs/plugin-basic-ssl gera um certificado não confiável, então você ainda verá este erro; aponte server.https para os arquivos do mkcert
• Dicas antigas que não funcionam mais — a opção chrome://flags/#allow-insecure-localhost expirou depois do Chrome 130 e não está mais em chrome://flags

# Install mkcert (macOS)
brew install mkcert
mkcert -install

# Generate localhost certificate
mkcert localhost 127.0.0.1 ::1
# Creates: localhost+2.pem and localhost+2-key.pem

# Use with Node.js
const https = require('https');
const fs = require('fs');
https.createServer({
  cert: fs.readFileSync('localhost+2.pem'),
  key: fs.readFileSync('localhost+2-key.pem')
}, app).listen(3000);

Erros de certificado SSL relacionados

NET::ERR_CERT_AUTHORITY_INVALID é um dos vários erros de certificado por trás da página “Sua conexão não é particular” do Chrome. Cada código aponta para uma verificação diferente: