Automatizar renovação SSL em vários domínios com cron consiste em executar periodicamente o Certbot por um script controlado, validar o resultado e recarregar o servidor web apenas quando houver renovação bem-sucedida. Para configurar a rotina com segurança, siga estes passos:
- Confirme que todos os certificados e domínios estão registrados no Certbot.
- Crie um script para renovar certificados e registrar erros.
- Configure um deploy hook para validar e recarregar o servidor web.
- Teste a renovação em modo de simulação, sem substituir certificados válidos.
- Agende o script no cron usando caminhos absolutos.
- Audite o log e confira os certificados publicados por cada domínio.
Pré-requisitos
A renovação automática de certificados requer acesso administrativo ao servidor e certificados já emitidos pelo cliente utilizado. O procedimento abaixo usa Certbot, cron e Nginx, com comandos compatíveis com distribuições atuais como Debian 13+, Rocky Linux 10+ e AlmaLinux 10+. O mesmo princípio pode ser adaptado ao Apache, alterando apenas a validação e a recarga do serviço.
- Acesso root ou usuário autorizado a usar sudo.
- Certbot instalado e com certificados existentes para os domínios.
- Nginx 1.28+ ativo e lendo os arquivos gerenciados pelo Certbot.
- Serviço cron instalado e em execução.
- Comando
flockdisponível para impedir execuções simultâneas. - DNS de cada domínio apontando para o servidor correto.
- Porta e método de validação do domínio acessíveis durante a renovação.
Antes de automatizar, confira a zona DNS. Um registro apontando para outro endereço pode impedir a confirmação do domínio; consulte o Guia de zona DNS: registros A, MX, CNAME e TXT do zero se precisar revisar os apontamentos.
Identificar certificados SSL de múltiplos domínios
O inventário de certificados SSL é a primeira etapa porque o comando de renovação trabalha sobre certificados já conhecidos pelo Certbot. Um único certificado pode incluir o domínio principal e seus subdomínios, enquanto instalações diferentes podem manter certificados separados. O importante é conferir se todas as entradas esperadas aparecem antes de criar o agendamento.
- Localize os executáveis usando o mesmo usuário que executará o cron.
- Liste os certificados registrados pelo Certbot.
- Confirme os nomes cobertos e os caminhos dos arquivos.
- Verifique se não existem certificados antigos ou duplicados.
command -v certbot
command -v flock
sudo certbot certificates
Output esperado:
o caminho absoluto do Certbot
o caminho absoluto do flock
certificados contendo seudominio.com.br e os subdomínios configurados
Ao rodar esses comandos, você verá os nomes administrados pelo cliente e poderá identificar domínios ausentes. Não crie entradas manuais dentro do diretório de certificados: o Certbot mantém referências próprias e espera controlar esses arquivos. Se um domínio não aparecer, ele precisa ter um certificado emitido corretamente antes de entrar na rotina de renovação.
Também confirme a resolução pública do domínio:
getent ahosts seudominio.com.br
Output esperado:
203.0.113.10 associado a seudominio.com.br
O endereço apresentado no servidor real deve corresponder ao IP público correto. O IP acima é apenas um endereço de documentação. Se o DNS estiver incorreto, corrija o apontamento e aguarde a resolução adequada antes do teste de renovação.
Criar o script de renovação SSL com Certbot
Um script de renovação SSL centraliza o ambiente, aplica bloqueio contra concorrência e devolve um código de saída que o cron pode registrar. O Certbot percorre os certificados existentes e decide quais estão dentro da janela de renovação; portanto, não é necessário criar um comando diferente para cada domínio.
Atenção: os comandos seguintes criam ou substituem arquivos em /usr/local/sbin. Faça uma cópia se esses caminhos já forem usados por scripts próprios.
sudo cp -a /usr/local/sbin/renovar-ssl-multidominio.sh /usr/local/sbin/renovar-ssl-multidominio.sh.bak 2>/dev/null || true
sudo tee /usr/local/sbin/renovar-ssl-multidominio.sh >/dev/null <<'EOF'
#!/bin/bash
set -u
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
CERTBOT=/usr/bin/certbot
FLOCK=/usr/bin/flock
LOCK=/run/lock/renovar-ssl-multidominio.lock
exec 9>"$LOCK"
if ! "$FLOCK" -n 9; then
echo "Outra renovação SSL já está em execução."
exit 1
fi
echo "Iniciando verificação dos certificados SSL."
"$CERTBOT" renew --deploy-hook /usr/local/sbin/recarregar-nginx-ssl.sh
STATUS=$?
if [ "$STATUS" -eq 0 ]; then
echo "Verificação de renovação concluída."
else
echo "Falha na renovação SSL. Código de saída: $STATUS"
fi
exit "$STATUS"
EOF
sudo chmod 750 /usr/local/sbin/renovar-ssl-multidominio.sh
sudo chown root:root /usr/local/sbin/renovar-ssl-multidominio.sh
sudo bash -n /usr/local/sbin/renovar-ssl-multidominio.sh
Output esperado:
nenhuma saída após a validação de sintaxe
O bloqueio com flock evita que duas execuções concorrentes alterem o mesmo estado. O PATH explícito reduz diferenças entre o terminal interativo e o ambiente limitado do cron. Já o deploy hook é chamado depois de uma renovação bem-sucedida, evitando recarregar o Nginx quando nenhum certificado foi alterado.
Automatizar renovação SSL em vários domínios com cron e deploy hook
Crie o hook separado para validar a configuração antes da recarga. Essa divisão facilita testar a etapa do servidor web sem executar todo o processo novamente.
sudo tee /usr/local/sbin/recarregar-nginx-ssl.sh >/dev/null <<'EOF'
#!/bin/bash
set -u
NGINX=/usr/sbin/nginx
SYSTEMCTL=/usr/bin/systemctl
if "$NGINX" -t; then
"$SYSTEMCTL" reload nginx
echo "Nginx validado e recarregado."
else
echo "Configuração do Nginx inválida; recarga cancelada."
exit 1
fi
EOF
sudo chmod 750 /usr/local/sbin/recarregar-nginx-ssl.sh
sudo chown root:root /usr/local/sbin/recarregar-nginx-ssl.sh
sudo bash -n /usr/local/sbin/recarregar-nginx-ssl.sh
Output esperado:
nenhuma saída após a validação de sintaxe
Testar a renovação automática sem alterar certificados
O teste de renovação SSL deve ocorrer antes da ativação do cron. O modo de simulação verifica o fluxo do cliente sem substituir os certificados válidos. A opção que executa deploy hooks durante a simulação também permite confirmar se a validação e a recarga do Nginx funcionam como esperado.
- Valide diretamente a configuração atual do Nginx.
- Execute o Certbot em modo de simulação.
- Confira o código de saída.
- Verifique se o serviço continuou ativo após o hook.
sudo /usr/sbin/nginx -t
sudo /usr/bin/certbot renew --dry-run --run-deploy-hooks
echo $?
sudo /usr/bin/systemctl is-active nginx
Output esperado:
teste de configuração do Nginx bem-sucedido
simulação de renovação concluída
código de saída 0
active
Não considere o processo validado apenas porque o comando foi iniciado. Leia toda a saída, confirme o código zero e procure falhas específicas em cada certificado. Em um conjunto com vários domínios, uma autorização pode funcionar enquanto outra falha por DNS, redirecionamento, bloqueio ou configuração divergente.
Se o site ainda aceitar HTTP para validação ou redirecionamento, preserve o caminho necessário ao cliente. Para revisar o comportamento geral do redirecionamento, consulte Como redirecionar um site HTTP para HTTPS?.
Agendar o Certbot no cron e salvar logs
O agendamento cron deve usar caminhos absolutos, um horário definido e redirecionamento de saída para um log persistente. O cron apenas inicia a verificação; quem determina se um certificado precisa ser renovado é o Certbot. Isso permite executar a rotina periodicamente sem substituir certificados em todas as execuções.
Atenção: não mantenha dois agendamentos para a mesma renovação. Verifique primeiro se já existe timer, cron do pacote ou tarefa administrativa executando o Certbot.
sudo crontab -l
sudo systemctl list-timers --all | grep -i certbot || true
Output esperado:
tarefas existentes do root e, quando houver, timers relacionados ao Certbot
Se não houver outra rotina ativa, crie um arquivo dedicado:
sudo tee /etc/cron.d/renovar-ssl-multidominio >/dev/null <<'EOF'
17 3 * * * root /usr/local/sbin/renovar-ssl-multidominio.sh >> /var/log/renovar-ssl-multidominio.log 2>&1
EOF
sudo chmod 644 /etc/cron.d/renovar-ssl-multidominio
sudo chown root:root /etc/cron.d/renovar-ssl-multidominio
sudo cat /etc/cron.d/renovar-ssl-multidominio
Output esperado:
17 3 * * * root /usr/local/sbin/renovar-ssl-multidominio.sh >> /var/log/renovar-ssl-multidominio.log 2>&1
Execute o script manualmente uma vez para criar o log e reproduzir o ambiente do cron:
sudo /usr/local/sbin/renovar-ssl-multidominio.sh >> /var/log/renovar-ssl-multidominio.log 2>&1
echo $?
sudo tail -n 30 /var/log/renovar-ssl-multidominio.log
Output esperado:
código de saída 0
registro de início e conclusão da verificação
Validar os certificados publicados após a renovação
A auditoria do certificado HTTPS precisa verificar o arquivo local e o certificado realmente entregue na porta 443. Essa comparação identifica situações em que a renovação ocorreu, mas o servidor web ainda apresenta um certificado anterior por falta de recarga ou por usar outro caminho.
sudo openssl x509 -in /etc/letsencrypt/live/seudominio.com.br/fullchain.pem -noout -subject -issuer -dates
echo | openssl s_client -connect seudominio.com.br:443 -servername seudominio.com.br 2>/dev/null | openssl x509 -noout -subject -issuer -dates
Output esperado:
assunto, emissor e período do certificado local
assunto, emissor e período do certificado publicado
Os dados relevantes devem corresponder. Repita a consulta com o nome de cada domínio ou subdomínio atendido pelo servidor, sempre usando o mesmo nome em -connect e -servername. Esse último parâmetro é essencial em ambientes que hospedam vários sites no mesmo IP, pois seleciona o virtual host correto.
Para acompanhar a automação, revise periodicamente o log do script e o log mantido pelo cliente de certificados:
sudo tail -n 50 /var/log/renovar-ssl-multidominio.log
sudo tail -n 50 /var/log/letsencrypt/letsencrypt.log
Output esperado:
execuções recentes, certificados verificados e eventuais mensagens de erro
Problemas comuns e como resolver
Falhas na renovação automática geralmente aparecem no DNS, no método de validação, nas permissões ou no ambiente reduzido do cron. O diagnóstico deve começar pelo código de saída e pelos logs, sem apagar certificados ou emitir novas cópias como primeira tentativa.
Sintoma: o script funciona no terminal, mas falha no cron
Causa: o cron usa ambiente e PATH diferentes, ou a tarefa foi cadastrada para um usuário sem permissões.
Solução: mantenha caminhos absolutos, execute a tarefa como root quando necessário e confira o arquivo de log. Valide também as permissões dos dois scripts e do diretório de bloqueio.
Sintoma: apenas um dos domínios não renova
Causa: DNS incorreto, virtual host divergente ou método de confirmação inacessível para aquele nome.
Solução: consulte a resolução do domínio, examine o log específico da autorização e teste o acesso esperado pelo método configurado. Não altere os outros certificados que já renovam normalmente.
Sintoma: o certificado foi renovado, mas o navegador mostra o antigo
Causa: o Nginx não foi recarregado ou o virtual host aponta para outro arquivo.
Solução: valide a configuração, compare o certificado local com o publicado e confirme os caminhos configurados no host. Depois, execute uma recarga, não uma interrupção completa do serviço.
Sintoma: o Nginx rejeita a recarga
Causa: existe erro de sintaxe ou referência inválida na configuração.
Solução: rode /usr/sbin/nginx -t, corrija o arquivo indicado e repita o teste. O hook proposto cancela a recarga quando a validação falha, preservando o processo já ativo.
Perguntas frequentes sobre automatizar renovação SSL em vários domínios com cron
Como automatizar a renovação SSL de vários domínios com cron?
Crie um script que execute o cliente de certificados para todos os domínios, valide o resultado e recarregue o servidor web somente após uma renovação bem-sucedida. Depois, agende o script no cron e registre a saída em um arquivo de log para facilitar a auditoria.
Com que frequência o cron deve verificar os certificados SSL?
O cron pode executar a verificação periodicamente, enquanto o cliente de certificados decide se cada certificado já está dentro da janela de renovação. Isso evita depender de uma execução próxima ao vencimento e reduz o risco de expiração por falhas não percebidas.
Como testar o script de renovação SSL sem substituir certificados válidos?
Use o modo de simulação oferecido pelo cliente de certificados antes de ativar o agendamento definitivo. Verifique o código de saída, os logs e a etapa de recarga do servidor web sem alterar certificados válidos.
É necessário reiniciar o Nginx ou Apache depois da renovação SSL?
O servidor web precisa recarregar a configuração para passar a usar os arquivos renovados, mas normalmente não é necessário interromper completamente o serviço. Antes da recarga, valide a configuração para evitar que um erro impeça o servidor de continuar atendendo os domínios.
Como descobrir por que a renovação automática do SSL falhou?
Consulte o log do script e do cliente de certificados, confirme as permissões de execução e verifique se o cron possui o mesmo ambiente esperado pelo comando. Também valide DNS, acesso ao método de confirmação do domínio e caminhos absolutos dos executáveis e arquivos.
Conclusão
A gestão de certificados em múltiplos domínios fica mais previsível quando renovação, validação, recarga e auditoria são etapas separadas. O cron inicia a rotina, o Certbot decide o que precisa ser renovado e o deploy hook só recarrega o servidor após uma alteração válida.
- Teste o fluxo completo com simulação antes de ativar o cron.
- Mantenha apenas um agendamento e acompanhe seus logs.
- Compare regularmente o certificado local com o publicado em cada domínio.
Leia também
- Passo a passo para configurar backup automático com cron no VPS Linux e servidor dedicado
- Entenda o que é Cron: automatização de tarefas no Linux
- configurar cron job no cPanel: causa e solução completa
Precisa de ajuda com renovação SSL automatizada?
Uma infraestrutura bem configurada facilita executar cron, Certbot e Nginx com controle de permissões e logs. Conheça opções de servidor para hospedar múltiplos domínios e administrar suas rotinas SSL.