Certificado SSL expirou - o que fazer

Em resumo: A expiração de um certificado SSL faz com que os navegadores bloqueiem o acesso com a mensagem "A sua ligação não é privada". A conversão cai a zero até renovares o certificado. Este artigo é um procedimento rápido sobre o que fazer imediatamente e como prevenir.

O que o visitante vê

Um certificado expirado dispara um aviso em ecrã inteiro no navegador:

• Chrome / Edge: "Your connection is not private" (NET::ERR_CERT_DATE_INVALID)
• Firefox: "Warning: Potential Security Risk Ahead" (SEC_ERROR_EXPIRED_CERTIFICATE)
• Safari: "This Connection Is Not Private"

Um visitante normal clica em "Voltar". Mais de 95 % do tráfego orgânico simplesmente sai. Os bot crawlers (Googlebot, Bingbot) param de indexar e após alguns dias começas a perder posições na pesquisa.

Procedimento se acabou de expirar

1. Identifica quem emitiu o cert. No terminal: openssl s_client -connect mywebsite.com:443 -servername mywebsite.com < /dev/null 2>/dev/null | openssl x509 -noout -issuer -dates
2. Let's Encrypt (grátis, validade 90 dias): tipicamente via certbot renew ou pelo painel do alojamento (One-click renewal).
3. Cert comercial (DigiCert, Sectigo, GlobalSign): faz login no painel admin do emissor, gera novo CSR, passa pela validação do domínio (DNS TXT ou email).
4. Implanta o novo cert no reverse proxy (nginx, Caddy, Traefik) e reinicia / faz reload do processo.
5. Verifica via SSL Labs ou pela nossa ferramenta SSL check, se o cert está a ser servido corretamente e a chain está completa.

Atenção: Não esqueças do cert intermédio - sem ele os navegadores modernos conseguem puxar a chain via AIA, mas clientes mais antigos e algumas bibliotecas API vão falhar.

Renovação automática: Let's Encrypt + certbot

A prevenção mais simples é automatizar completamente a renovação. O cert Let's Encrypt renova-se a cada 90 dias via certbot:

# /etc/cron.d/certbot-renew
0 3 * * * root certbot renew --quiet --deploy-hook "systemctl reload nginx"

Este cron corre diariamente às 3:00 da manhã. O certbot internamente verifica se o cert se aproxima da expiração (por defeito 30 dias antes). Se sim, renova-o e em caso de sucesso faz reload do nginx. Caso contrário não faz nada.

Caddy e Traefik: totalmente automático

Se usas Caddy ou Traefik como reverse proxy, o ACME challenge está integrado no binário. Basta marcar o domínio no config e o servidor pede e renova o cert por si:

# Caddyfile
mywebsite.com {
  reverse_proxy localhost:3000
}

Sem certbot, sem cron. O Caddy chama em background a API do Let's Encrypt e gere o ciclo de renovação.

Certs comerciais: validade 1-3 anos

Desde setembro de 2020 todos os certs publicamente confiáveis têm vida máxima de 397 dias (CA/B Forum baseline). Algumas empresas continuam a preferir CAs comerciais por:

• Extended Validation (EV) mostra a organização na barra de endereço (o Chrome já não a mostra de forma proeminente desde 2019).
• Wildcard para muitos subdomínios embora o Let's Encrypt já suporte wildcards via DNS-01.
• Garantia responsabilidade financeira da CA em caso de compromise.
• Compliance / auditoria alguns setores têm requisitos externos.

Para a maioria dos sites Let's Encrypt ou outra CA grátis (ZeroSSL, Buypass) chegam.

Monitorização de expiração como rede de segurança

Mesmo com renovação automática, a monitorização de expiração funciona como seguro. A renovação pode falhar por:

• Rate limit do lado da CA (Let's Encrypt: 5 duplicados / 7 dias)
• Alteração DNS que parte o ACME challenge
• Regra de firewall a bloquear a porta 80 (HTTP-01 challenge)
• Queda do processo certbot ou do cron que ninguém reparou

O ePulz.io segue a expiração de cada endpoint monitorizado e envia alerta 30, 14, 7, 3 e 1 dia antes do fim da validade. Basta um sinal verde de que o cert se renovou a tempo - e tens a certeza de que a automação funciona.

Ativa a monitorização SSL

Alertas 30/14/7/3/1 dias antes da expiração. Sem configuração, sem alterações DNS. 7 dias grátis.

Iniciar monitorização →