Renovar SSL automaticamente com Certbot e cron no Linux

Certificados emitidos pelo Let’s Encrypt têm validade de 90 dias — uma decisão intencional do projeto pra forçar automação e reduzir janela de exposição em caso de comprometimento. Renovação manual a cada 60-80 dias é insustentável em produção: basta uma viagem, um plantão sobrecarregado ou um servidor esquecido pra TLS expirar e o site começar a retornar ERR_CERT_DATE_INVALID no navegador dos clientes.

Este tutorial é pra sysadmins e desenvolvedores que já têm Certbot instalado e ao menos um certificado emitido, e querem garantir que a renovação rode sem intervenção, recarregue o servidor web sem downtime e avise se algo quebrar. Vamos cobrir as duas abordagens — cron clássico e systemd timer — escolher quando usar cada uma, configurar deploy hooks pra reload do Nginx/Apache e montar um monitoramento básico.

Tempo estimado de execução: 15 a 25 minutos, dependendo de quantos domínios você gerencia e se vai configurar alertas customizados.

Pré-requisitos

Confirme a versão do Certbot e a presença de pelo menos um certificado antes de prosseguir:

certbot --version
sudo certbot certificates

A saída de certbot certificates deve listar cada certificado com nome, domínios cobertos e data de expiração. Se nada aparece, emita um primeiro certificado antes de configurar a automação — esta documentação assume que a etapa de emissão inicial já foi feita.

Verificando se o timer systemd já está ativo

Em distros modernas o pacote certbot instala automaticamente uma unit systemd que cuida da renovação — antes de mexer em cron, confirme se ela já está rodando. A maioria das instalações Ubuntu 22.04+ não precisa de cron manual nenhum.

systemctl list-timers --all | grep -i certbot

systemctl cat certbot.timer

systemctl cat certbot.service

Configurando renovação via cron tradicional

Se você está em uma distro antiga, em um servidor sem systemd, ou simplesmente prefere cron, use esta abordagem. Em distros modernas, desabilite o timer antes pra evitar duas execuções concorrentes.

sudo systemctl disable --now certbot.timer

sudo crontab -e

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
0 3,15 * * * /usr/bin/certbot renew --quiet

sudo crontab -l

Configurando deploy hook pra reload sem downtime

Renovar o certificado não basta — o Nginx ou Apache continua usando o cert antigo carregado em memória até receber sinal pra recarregar. Deploy hooks resolvem isso elegantemente.

sudo mkdir -p /etc/letsencrypt/renewal-hooks/deploy
sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh > /dev/null <<'EOF'
#!/bin/bash
systemctl reload nginx
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-apache.sh > /dev/null <<'EOF'
#!/bin/bash
systemctl reload apache2
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-apache.sh

sudo certbot renew --dry-run

Monitorando renovação

Automação sem observabilidade é uma armadilha — descobrir que o cert expirou pelo erro do navegador é o pior cenário possível. Monte um check ativo que avise antes.

sudo tee /usr/local/bin/check-ssl-expiry.sh > /dev/null <<'EOF'
#!/bin/bash
THRESHOLD_DAYS=20
ALERT_EMAIL="[email protected]"

for cert in /etc/letsencrypt/live/*/cert.pem; do
  domain=$(basename "$(dirname "$cert")")
  end_date=$(openssl x509 -enddate -noout -in "$cert" | cut -d= -f2)
  end_epoch=$(date -d "$end_date" +%s)
  now_epoch=$(date +%s)
  days_left=$(( (end_epoch - now_epoch) / 86400 ))

  if [ "$days_left" -lt "$THRESHOLD_DAYS" ]; then
    echo "ALERTA: $domain expira em $days_left dias" | \
      mail -s "SSL expirando: $domain" "$ALERT_EMAIL"
  fi
done
EOF
sudo chmod +x /usr/local/bin/check-ssl-expiry.sh

echo "30 8 * * * /usr/local/bin/check-ssl-expiry.sh" | sudo tee -a /etc/crontab

Verificação final

Rode os comandos abaixo pra confirmar que toda a configuração está ativa:

sudo certbot renew --dry-run
systemctl list-timers --all | grep certbot
ls -la /etc/letsencrypt/renewal-hooks/deploy/
sudo /usr/local/bin/check-ssl-expiry.sh

O dry-run deve passar sem erros. O timer (se você optou por systemd) deve estar ativo. Os hooks devem ser executáveis. O script de check não deve emitir alerta — se emitir, o cert está em janela crítica e você precisa investigar logs em /var/log/letsencrypt/letsencrypt.log.

Resolução de problemas

”Failed authorization procedure” no renew

Causa comum: porta 80 bloqueada por firewall ou redirecionada pra 443 sem exceção pro path /.well-known/acme-challenge/. Certbot precisa servir o desafio HTTP-01 nessa rota. Confirme com curl http://seu-dominio/.well-known/acme-challenge/test — deve retornar 404 do seu servidor, não erro de conexão. Se você força redirect global pra HTTPS, adicione exceção pra esse path no Nginx.

”Hook command exited with code 1”

O script do hook retornou erro. Rode manualmente pra debugar: sudo bash /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh. Erros típicos: nginx config inválida (nginx -t primeiro), serviço não rodando, ou permissões erradas no script.

Timer aparece ativo mas nunca renova

Verifique horário do servidor com timedatectl — se o relógio está incorreto, o timer dispara mas o certbot rejeita a operação. Sincronize com sudo systemctl restart systemd-timesyncd. Outro caso: o cert ainda não está em janela de 30 dias antes de expirar; certbot ignora silenciosamente. Force com --force-renewal apenas se confirmou outras causas.

Próximos passos

Com renovação automatizada e monitorada, considere estes próximos passos pra aumentar a robustez do seu setup TLS:

• Configurar OCSP stapling no Nginx — reduz latência da validação do cert no navegador e diminui carga nos servidores OCSP do Let’s Encrypt.
• Avaliar wildcard certificates com DNS-01 challenge — útil se você gerencia muitos subdomínios; requer plugin DNS específico do seu provedor.
• Implementar HSTS preload após confirmar estabilidade da renovação — comprometedor de reverter, então só ative quando a automação rodou por pelo menos 2 ciclos completos.
• Centralizar logs de renovação em um sistema de observabilidade — útil em fleets de servidores onde checar cada máquina individualmente não escala.

Se você está colocando isso em produção, uma VPS Hostini já vem com Ubuntu LTS atualizado, SSH endurecido por padrão e tráfego com proteção DDoS — base sólida pra automações de TLS sem surpresas no kernel ou na rede.