Como automatizar a renovação de certificado SSL do site do seu servidor de MU Online
Configure o Certbot com Let's Encrypt para renovar automaticamente o certificado SSL do site, painel de conta e loja do seu servidor de MU Online, evitando quedas de HTTPS e alertas de site inseguro.
Um certificado SSL vencido é um dos incidentes mais evitáveis — e mais prejudiciais à imagem — que um servidor de MU Online pode sofrer: de um dia para o outro, o site, o painel de conta e a loja passam a exibir "conexão não segura" no navegador, afastando jogadores e travando pagamentos. A causa qu
Um certificado SSL vencido é um dos incidentes mais evitáveis — e mais prejudiciais à imagem — que um servidor de MU Online pode sofrer: de um dia para o outro, o site, o painel de conta e a loja passam a exibir "conexão não segura" no navegador, afastando jogadores e travando pagamentos. A causa quase sempre é a mesma: o certificado foi emitido manualmente uma vez e ninguém configurou a renovação automática. Este tutorial mostra como usar o Certbot com Let's Encrypt para emitir e renovar certificados automaticamente, cobrindo Nginx, Apache e a alternativa para Windows/IIS, além dos testes e alertas que garantem que isso nunca mais vire um problema.
Por que HTTPS é obrigatório para o site do servidor
Além do cadeado no navegador, o HTTPS protege credenciais de login, dados de pagamento na loja de itens e cookies de sessão contra interceptação. Navegadores modernos (Chrome, Firefox, Edge) bloqueiam ou alertam agressivamente sites sem HTTPS, e mecanismos de busca penalizam o ranqueamento de páginas sem certificado válido — para um servidor que depende de divulgação orgânica, isso tem impacto direto em novos cadastros.
Entendendo o ciclo de vida do certificado Let's Encrypt
Diferente de certificados comerciais tradicionais (que podem durar 1 a 2 anos), os certificados do Let's Encrypt têm validade de 90 dias, por design — isso reduz o risco de uso indevido de certificados esquecidos e força a existência de automação. A expectativa do próprio Let's Encrypt é que a renovação seja automática; renovar manualmente a cada 3 meses é o tipo de tarefa que qualquer equipe acaba esquecendo.
| Marco | Ação esperada |
|---|---|
| Dia 0 | Certificado emitido |
| Dia 60 | Certbot já tenta renovar automaticamente (30 dias antes do vencimento) |
| Dia 90 | Vencimento — nunca deveria ser alcançado sem renovação prévia |
Instalando o Certbot no servidor (Linux + Nginx)
Em distribuições baseadas em Debian/Ubuntu, a instalação via snap é a recomendada oficialmente por manter o Certbot sempre atualizado:
sudo apt update
sudo apt install -y snapd
sudo snap install core; sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
Emitindo o certificado para o domínio do servidor
Com o Nginx já configurado e respondendo na porta 80 para o domínio (ex.: meuservidor.com e www.meuservidor.com), a emissão é interativa e cuida também da configuração do bloco HTTPS:
sudo certbot --nginx -d meuservidor.com -d www.meuservidor.com -d loja.meuservidor.com
O Certbot detecta os blocos server existentes no Nginx, adiciona automaticamente as diretivas listen 443 ssl e os caminhos dos arquivos de certificado, e oferece redirecionar todo o tráfego HTTP para HTTPS — aceite essa opção, é a prática recomendada.
Configuração equivalente para Apache
Se o site do servidor roda em Apache em vez de Nginx, o plugin correspondente segue a mesma lógica:
sudo apt install -y python3-certbot-apache
sudo certbot --apache -d meuservidor.com -d www.meuservidor.com
Verificando a renovação automática (systemd timer)
Instalações modernas do Certbot já registram um systemd timer que roda duas vezes ao dia verificando certificados perto do vencimento. Confirme que está ativo:
systemctl status certbot.timer
sudo certbot renew --dry-run
O --dry-run simula o processo completo de renovação sem de fato substituir o certificado — se ele terminar sem erro, a automação está funcionando corretamente.
Alternativa via cron (sistemas sem systemd timer)
Em ambientes mais antigos onde o timer não é instalado automaticamente, adicione a entrada de cron manualmente:
0 3,15 * * * /usr/bin/certbot renew --quiet --deploy-hook "systemctl reload nginx"
Rodar duas vezes ao dia (03h e 15h) é a prática recomendada pela própria documentação do Let's Encrypt, pois distribui a carga dos servidores de validação e aumenta a chance de sucesso mesmo se uma tentativa falhar por instabilidade momentânea de rede.
O hook de deploy: recarregando o servidor web sem downtime
A flag --deploy-hook executa um comando só quando a renovação realmente acontece (não em toda verificação), garantindo que o novo certificado seja carregado sem precisar derrubar o site:
sudo certbot renew --deploy-hook "systemctl reload nginx"
Um reload (não restart) é suficiente para o Nginx/Apache carregarem o certificado novo, mantendo as conexões existentes ativas — o jogador navegando no site não percebe nada.
Certificado wildcard para subdomínios (painel, loja, forum)
Servidores de MU costumam ter vários subdomínios (painel., loja., forum., api.). Em vez de emitir um certificado por subdomínio, um certificado wildcard (*.meuservidor.com) cobre todos de uma vez, mas exige validação via DNS (TXT record), não via HTTP:
sudo certbot certonly --manual --preferred-challenges dns \
-d meuservidor.com -d "*.meuservidor.com"
Para automatizar totalmente o wildcard (sem intervenção manual a cada renovação), use um plugin de DNS específico do seu provedor (Cloudflare, Route53, etc.), que insere e remove o TXT record automaticamente via API.
Automatizando o wildcard com Cloudflare (exemplo)
Se o domínio do servidor está na Cloudflare, o plugin certbot-dns-cloudflare elimina a etapa manual do desafio DNS:
sudo apt install -y python3-certbot-dns-cloudflare
# /etc/letsencrypt/cloudflare.ini
dns_cloudflare_api_token = SEU_TOKEN_AQUI
chmod 600 /etc/letsencrypt/cloudflare.ini
sudo certbot certonly --dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
-d meuservidor.com -d "*.meuservidor.com"
Com isso, mesmo o certificado wildcard renova sozinho pelo systemd timer, sem qualquer clique manual a cada 90 dias.
Alertando antes do vencimento (camada extra de segurança)
Mesmo com automação, é prudente ter um alerta independente monitorando a data de expiração real do certificado em produção, caso a renovação falhe silenciosamente por qualquer motivo (rate limit, DNS fora do ar, etc.):
DIAS_RESTANTES=$(echo | openssl s_client -servername meuservidor.com -connect meuservidor.com:443 2>/dev/null | \
openssl x509 -noout -enddate | cut -d= -f2 | xargs -I{} date -d {} +%s | \
xargs -I{} echo "(({} - $(date +%s)) / 86400)" | bc)
if [ "$DIAS_RESTANTES" -lt 15 ]; then
curl -s -X POST "$DISCORD_WEBHOOK_URL" -H "Content-Type: application/json" \
-d "{\"content\":\"⚠️ Certificado SSL vence em $DIAS_RESTANTES dias!\"}"
fi
Erros comuns e soluções
| Sintoma | Causa provável | Solução |
|---|---|---|
| Navegador exibe "conexão não segura" | Certificado expirou sem renovação | Rode certbot renew manualmente e investigue por que a automação falhou |
certbot renew --dry-run falha | Porta 80 bloqueada por firewall | Libere a porta 80 para o desafio HTTP-01 do Let's Encrypt |
| Renovação de wildcard não automatiza | Validação DNS manual sem plugin de API | Configure o plugin certbot-dns-<provedor> correspondente |
| Site fica fora do ar após renovação | Deploy-hook ausente, config não recarregada | Adicione --deploy-hook "systemctl reload nginx" |
| Rate limit do Let's Encrypt atingido | Muitas emissões repetidas em pouco tempo | Use --dry-run para testes; emita de fato só quando necessário |
| Certificado emitido mas subdomínio novo não coberto | Subdomínio não incluído nos -d na emissão | Reemita incluindo todos os subdomínios ou use wildcard |
Checklist de SSL automatizado
- Certbot instalado e certificado emitido para todos os domínios/subdomínios ativos.
- Redirecionamento HTTP → HTTPS confirmado no Nginx/Apache.
certbot renew --dry-runexecutado sem erros.systemd timerou cron de renovação confirmado ativo.- Deploy-hook de reload do servidor web configurado.
- Wildcard configurado via plugin de DNS, se aplicável.
- Alerta independente de expiração (openssl + webhook) implementado.
Com a renovação de SSL totalmente automatizada, o site, o painel de conta e a loja do servidor deixam de correr o risco de aparecer como "inseguros" para os jogadores. Se você ainda está estruturando o ambiente web do zero, veja também o tutorial de criação de servidor de MU Online para alinhar a infraestrutura de site com a do GameServer.
Perguntas frequentes
O certificado Let's Encrypt é realmente gratuito para sempre?
Sim, o Let's Encrypt é um serviço gratuito e sem fins lucrativos mantido pela Internet Security Research Group. Não há custo para emitir ou renovar certificados, desde que a renovação automática esteja configurada — o certificado expira a cada 90 dias e precisa ser renovado antes disso.
O que acontece se o certificado expirar sem eu perceber?
O navegador do jogador passa a mostrar um aviso de 'conexão não segura' ao acessar o site, painel de conta ou loja, o que derruba drasticamente a confiança e as conversões de venda. Formulários de login e pagamento podem parar de funcionar em navegadores mais restritivos.
Preciso renovar manualmente a cada 90 dias?
Não, se a automação estiver configurada corretamente. O Certbot instala por padrão uma tarefa (cron ou systemd timer) que verifica diariamente se o certificado está a menos de 30 dias do vencimento e renova automaticamente quando necessário.
Funciona com qualquer servidor web (Nginx, Apache, IIS)?
O Certbot tem suporte nativo a Nginx e Apache no Linux. Para IIS no Windows, a alternativa mais usada é o win-acme (também baseado em Let's Encrypt) com um agendamento equivalente via Agendador de Tarefas.
Preciso reiniciar o site toda vez que o certificado renova?
Depende do servidor web. Nginx e Apache normalmente só precisam de um reload (não um restart completo) para carregar o novo certificado, o que o Certbot já faz automaticamente via hook pós-renovação, sem downtime perceptível.