Certbot via systemd timer: como verificar se a renovação automática realmente está funcionando

Ter Certbot instalado não prova que o certificado vai renovar sozinho.

Em uma coleta real, systemctl list-timers mostrava uma unidade de renovação do Certbot com execução anterior registrada e uma próxima execução agendada poucas horas depois.

Esse é um bom começo.

Mas a verificação que eu quero responder é mais completa:

o scheduler existe, executa, encontra os certificados certos e consegue renovar sem intervenção?

Comece pelo timer real #

Dependendo de como Certbot foi instalado, o nome da unidade pode variar.

No ambiente recuperado, aparecia algo como:

1
snap.certbot.renew.timer

Então eu começaria com:

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

E depois:

1
systemctl status snap.certbot.renew.timer --no-pager

ou, em instalação via pacote:

1
systemctl status certbot.timer --no-pager

O nome correto deve vir do host, não de uma receita copiada.

`list-timers` responde duas perguntas importantes #

A saída mostra normalmente:

1
2
3
4
LAST
NEXT
UNIT
ACTIVATES

Se existe um LAST recente e um NEXT futuro, há evidência de que o systemd está agendando a unidade.

Isso ainda não prova que a renovação de um certificado específico teve sucesso.

O timer pode executar e o comando falhar.

Veja o serviço acionado pelo timer #

1
systemctl cat snap.certbot.renew.service

ou:

1
systemctl cat certbot.service

Depois consulte o journal:

1
2
journalctl -u snap.certbot.renew.service \
  --since '7 days ago' --no-pager

O objetivo é separar:

1
2
3
4
5
timer disparou
serviço iniciou
certbot executou
renovação foi necessária ou não
houve erro de challenge/deploy hook

Liste o que o Certbot acredita administrar #

1
certbot certificates

Isso mostra, entre outras coisas:

nomes cobertos;
validade;
caminho do certificado;
caminho da chave;
configuração de renewal associada.

É útil comparar isso com a configuração efetiva do servidor web.

No Nginx:

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

Um certificado pode renovar corretamente e o Nginx continuar apontando para outro arquivo.

O teste mais importante é o dry-run #

Quando a operação permitir:

1
certbot renew --dry-run

Esse teste simula o processo de renovação com o ambiente de staging do ACME e ajuda a encontrar problemas antes da expiração real.

Ele pode revelar:

DNS apontando para lugar errado;
porta/challenge inacessível;
plugin ausente;
configuração antiga;
hook com erro;
autenticação DNS inválida.

O resultado precisa ser lido; rodar o comando não basta.

Valide também o certificado entregue externamente #

O arquivo local pode estar correto enquanto o cliente recebe outro certificado de uma CDN, proxy ou load balancer.

Uma verificação externa:

1
2
3
4
5
openssl s_client \
  -connect app.example.com:443 \
  -servername app.example.com \
  </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Ou:

1
curl -vkI https://app.example.com/

Assim você confirma o que está realmente sendo apresentado na borda consultada.

Cuidado com instalações duplicadas #

É possível encontrar Certbot instalado por mecanismos diferentes no mesmo host, por exemplo pacote e snap.

Isso pode criar timers ou caminhos diferentes e dificultar a resposta:

quem renova este certificado?

Eu verificaria:

1
2
3
4
5
which certbot
readlink -f "$(command -v certbot)"
snap list certbot 2>/dev/null
systemctl list-timers --all | grep -i certbot
crontab -l 2>/dev/null | grep -i certbot

Também:

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

O objetivo é ter um mecanismo deliberado, não vários schedulers concorrentes sem documentação.

O que a fonte deste artigo prova #

A coleta técnica recuperada mostra um servidor Linux com:

timer de renovação Certbot gerenciado por systemd/snap;
execução anterior registrada;
próxima execução agendada;
outros timers do sistema coexistindo normalmente.

Ela não é usada para afirmar que um certificado específico estava perto de expirar ou que houve uma falha de renovação.

O artigo transforma aquela evidência em um checklist de validação do mecanismo.

Checklist #

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
[ ] timer Certbot identificado
[ ] unidade está ativa
[ ] LAST e NEXT fazem sentido
[ ] serviço acionado conhecido
[ ] journal sem erro relevante
[ ] certbot certificates revisado
[ ] Nginx/Apache aponta para o certificado esperado
[ ] certbot renew --dry-run passou
[ ] certificado externo conferido
[ ] nenhum segundo scheduler concorrente esquecido

O principal aprendizado #

Renovação automática não é uma configuração que eu marco como “feito” porque existe um timer.

Eu quero uma cadeia verificável:

1
2
3
4
5
6
7
scheduler
→ serviço
→ Certbot
→ challenge
→ certificado
→ reload/hook quando necessário
→ certificado entregue ao cliente

Só aí a palavra automática começa a ser confiável.