Certbot via cron a cada 12 horas: como validar o mecanismo sem duplicar renovação

Nem todo servidor usa certbot.timer.

Em um inventário real de hosts Docker, apareceu um servidor com Nginx local e Certbot em que a renovação estava agendada no cron do root:

0 */12 * * * certbot renew -q

Também havia uma entrada de /etc/cron.d/certbot com execução a cada 12 horas e um detalhe importante: ela só prosseguia quando o sistema não estava usando systemd para esse papel.

A pergunta útil não é se cron é “certo” ou “errado”.

É:

há exatamente um mecanismo de renovação efetivo e ele funciona?

Executar duas vezes por dia é normal para certbot renew #

certbot renew não renova todo certificado em toda execução.

Ele verifica os certificados gerenciados e só tenta renovar quando entram na janela aplicável.

Por isso, um scheduler frequente pode ser usado sem emitir certificado novo a cada chamada.

O problema aparece quando existem vários schedulers não coordenados.

Por exemplo:

1
2
3
4

root crontab
/etc/cron.d/certbot
certbot.timer
snap.certbot.renew.timer

Se ninguém sabe qual é o mecanismo oficial, troubleshooting e auditoria ficam confusos.

Primeiro inventarie todos os agendadores #

1

crontab -l 2>/dev/null | grep -i certbot

Depois:

1

grep -Rni 'certbot.*renew' /etc/cron.d /etc/cron.daily 2>/dev/null

E systemd:

1

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

Se o Certbot veio via snap:

1

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

Esse inventário responde quem pode disparar renovação.

O detalhe condicional de /etc/cron.d/certbot #

A fonte recuperada continha uma entrada conceitualmente parecida com:

0 */12 * * * root \
  test -x /usr/bin/certbot \
  -a \! -d /run/systemd/system \
  && ... \
  && certbot -q renew

O teste contra /run/systemd/system existe justamente para evitar que aquele cron clássico assuma a renovação quando o host está operando sob systemd.

Isso mostra por que ler a linha inteira importa.

Ver apenas 0 */12 e concluir “há cron concorrendo com timer” pode ser incorreto se a própria condição impede a execução nesse ambiente.

Já um cron direto não tem essa proteção #

Uma linha como:

0 */12 * * * certbot renew -q

executará no horário programado independentemente de existir outro timer, salvo algum controle dentro do próprio comando/pacote.

Se ela é deliberada, eu documentaria por quê.

Se é resíduo de uma instalação antiga, remover duplicidade pode simplificar a operação — depois de validar qual mecanismo deve permanecer.

Cron existir não prova sucesso #

O cron pode disparar e ainda falhar por:

• DNS incorreto;
• challenge inacessível;
• plugin ausente;
• credencial DNS inválida;
• configuração de renewal antiga;
• hook quebrado;
• servidor web sem reload quando necessário.

Por isso eu testaria:

1

certbot renew --dry-run

E revisaria os logs do Certbot.

Conforme instalação:

1

ls -lah /var/log/letsencrypt/

1

tail -n 200 /var/log/letsencrypt/letsencrypt.log

Confira os certificados gerenciados #

1

certbot certificates

Depois compare com o servidor web:

1

nginx -T | grep -E 'server_name|ssl_certificate|ssl_certificate_key'

Um scheduler saudável não ajuda se o Nginx entrega outro certificado.

O horário exato não é o ponto principal #

A coleta tinha execução de 12 em 12 horas.

O valor importante para o artigo não é recomendar exatamente 0 */12 para todos os hosts.

É entender que a frequência precisa deixar margem para novas tentativas antes do vencimento, sem criar loops agressivos ou múltiplos mecanismos concorrentes.

Certbot foi projetado para que renew seja chamado periodicamente e decida internamente se é hora de renovar.

Como eu decidiria entre cron e timer #

Em um host moderno com systemd e pacote/snap já fornecendo timer, eu tenderia a manter o mecanismo nativo da instalação.

Em ambiente legado ou específico que usa cron de forma deliberada, ele pode continuar sendo um scheduler válido desde que:

1
2
3
4
5

há apenas um fluxo efetivo
logs são verificáveis
dry-run passa
certificados gerenciados estão corretos
reload/hook funciona

A decisão é operacional, não religiosa.

O que a fonte prova #

O inventário recuperado comprova hosts com:

• Nginx local gerenciado com certificados Certbot;
• cron root 0 */12 * * * certbot renew -q;
• entrada tradicional em /etc/cron.d/certbot com guarda para não operar sob systemd;
• outros hosts da mesma frota sem esse cron, mostrando que a configuração não era universal.

O título original dizia “servidor sem certbot.timer”. A fonte recuperada prova o cron, mas não uma coleta completa de timers daquele mesmo host em todos os momentos. Por isso o título foi reduzido para não afirmar ausência que não está demonstrada.

Checklist #

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

[ ] root crontab verificado
[ ] /etc/cron.d verificado
[ ] timers systemd verificados
[ ] instalação snap/pacote identificada
[ ] exatamente um fluxo deliberado definido
[ ] certbot certificates conferido
[ ] certbot renew --dry-run passou
[ ] logs revisados
[ ] servidor web aponta para arquivos corretos
[ ] certificado externo conferido

O principal aprendizado #

Cron de 12 horas pode fazer parte de uma renovação perfeitamente operável.

O risco não é usar cron.

O risco é não saber quantos mecanismos estão tentando renovar, qual deles realmente roda e se algum deles já foi testado de ponta a ponta.