O que significa “Sua conexão não é particular” e como resolver

O que o erro significa

O navegador se conectou, o servidor apresentou o certificado e o navegador se recusou a confiar nele. O Chrome mostra “Sua conexão não é particular” com um código de erro; o Firefox diz “Alerta: risco potencial de segurança à frente”; o Safari, “Esta conexão não é particular”. Em Portugal, a mesma tela do Chrome diz “A sua ligação não é privada”. O site não foi invadido e seu aparelho não está infectado: o certificado que o servidor enviou não passa nas verificações do navegador.

O código do erro diz qual verificação falhou:

• NET::ERR_CERT_DATE_INVALID: o certificado venceu ou ainda não é válido (ou o relógio do visitante está errado).
• NET::ERR_CERT_COMMON_NAME_INVALID: o certificado vale para outro nome, por exemplo www.example.com mas não example.com.
• NET::ERR_CERT_AUTHORITY_INVALID: nenhuma autoridade reconhecida o garante: autoassinado, emissor desconhecido ou certificado intermediário faltando.
• NET::ERR_CERT_REVOKED: o emissor revogou o certificado.
• SSL_ERROR_BAD_CERT_DOMAIN e SEC_ERROR_EXPIRED_CERTIFICATE: as variantes do Firefox para nome e data.

Causas frequentes

1. O certificado venceu. Os certificados Let’s Encrypt valem 90 dias; a renovação automática vinha falhando há semanas sem ninguém ver, até o dia em que ele venceu. Certificados pagos vencem depois de um ano, e o lembrete foi para um e-mail antigo.
2. Renovado, mas sem recarregar. O certbot gravou o certificado novo no disco, mas o servidor web continua entregando o antigo porque falta o hook de recarga.
3. Nome errado. O certificado cobre example.com, mas os visitantes chegam por www.example.com, ou um subdomínio não tem certificado.
4. Falta o certificado intermediário. O servidor envia só o próprio certificado, não a cadeia. Navegadores de desktop costumam preencher a lacuna; celulares e apps falham.
5. Problema de relógio. No visitante, uma data errada faz todos os certificados parecerem vencidos ou ainda não válidos. No servidor, quebra a renovação.
6. Um CDN ou proxy na frente, com certificado próprio vencido ou sem o nome certo, enquanto o servidor de origem está em ordem.

Se você é visitante

Confira primeiro a data e a hora do aparelho; uma bateria da placa-mãe (CMOS) esgotada ou a sincronização de hora desligada fazem todos os sites falharem. Depois tente de outra rede. Se o aviso aparece só em um site, de qualquer aparelho, o problema é o certificado do site: só o dono corrige. Clicar em “Ir para … (não seguro)” serve para um site que você conhece, nunca para um com senha ou pagamento.

Se o site é seu: verifique primeiro

Abra o SSL checker: data de vencimento, nomes cobertos e cadeia completa ou não, visto de fora e sem o cache do navegador. Depois, no seu servidor:

# o que o servidor envia?
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject -ext subjectAltName

# o que está no disco?
sudo certbot certificates

# o relógio está certo?
timedatectl

Datas mais recentes no disco do que as que o servidor envia? Você está no caso 2: renovado, mas sem recarregar.

Soluções no seu servidor

1. Renovar com o certbot

sudo certbot renew
# se renew responder "not yet due" enquanto o servidor entrega um certificado antigo:
sudo certbot renew --force-renewal
sudo systemctl reload nginx     # ou apache2

Se a renovação falhar, o motivo está na saída. Os clássicos: a porta 80 está bloqueada ou redirecionada (o desafio HTTP-01 precisa chegar a /.well-known/acme-challenge/ em HTTP simples), o DNS aponta para outro lugar, ou um limite de pedidos foi atingido depois de muitas tentativas falhas. Corrija a causa e rode sudo certbot renew --dry-run até passar.

2. Automatizar a recarga

# Debian/Ubuntu: o certbot instala um timer; confira
systemctl list-timers | grep certbot

# hook para o servidor web pegar o certificado novo
printf '#!/bin/sh\nsystemctl reload nginx\n' | sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-web.sh
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-web.sh

3. Incluir o nome que falta

sudo certbot --nginx -d example.com -d www.example.com -d loja.example.com --expand

--expand substitui o certificado atual por um que cobre todos os nomes indicados.

4. Consertar a cadeia

Com o certbot, o servidor web precisa apontar para fullchain.pem, nunca para cert.pem:

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Apache: SSLCertificateFile com fullchain.pem. Para um certificado comprado, baixe o certificado intermediário (“CA bundle”) do emissor e acrescente ao arquivo do certificado. Teste com sudo nginx -t (Apache: sudo apachectl configtest), recarregue e confira a cadeia no SSL checker.

5. Acertar o relógio

sudo timedatectl set-ntp true
timedatectl

Um relógio com mais de alguns minutos de diferença faz a verificação dos certificados falhar nos dois sentidos.

6. Hospedagem compartilhada ou construtor de sites

A maioria das hospedagens emite e renova certificados Let’s Encrypt pelo painel do cliente (“SSL/TLS”, “Segurança”, “Let’s Encrypt”). Abra, confira se o certificado cobre example.com e www.example.com, e clique em renovar ou emitir de novo. Se o painel mostra um certificado válido enquanto os navegadores dizem o contrário, o problema de recarga ou de cadeia está na hospedagem.

Se o problema está na sua hospedagem

Prezados, desde aproximadamente 6h (UTC) os navegadores mostram “Sua conexão não é particular” (NET::ERR_CERT_DATE_INVALID) no meu site example.com. O painel do cliente mostra um certificado válido, então o servidor parece estar entregando ainda o antigo. Vocês poderiam recarregar o certificado no servidor e verificar a renovação automática do meu domínio?

Para não acontecer de novo

Um certificado vencido é a única falha com data conhecida de antemão. O monitoramento de certificados SSL avisa antes do vencimento, e também quando a cadeia ou o nome não estão certos; 5 verificações são grátis. O navegador nem chega a ler o certificado e mostra ERR_SSL_PROTOCOL_ERROR? É outro caso: a conexão segura falha antes do certificado. E se o servidor recusa a conexão direto na porta 443? Então é um ERR_CONNECTION_REFUSED.

Fora do ar? Nós resolvemos. No seu servidor ou em uma hospedagem compartilhada com acesso SSH, o Quick Fix, o reparo automático a preço fixo, renova o certificado onde o certbot está configurado e recarrega o servidor web, 24 horas por dia, inclusive nos fins de semana; o Deep Fix monta a renovação onde ela falta, em blocos de 15 minutos; a estimativa é o valor máximo.