Como resolver erro de certificado SSL inválido no site e launcher do seu servidor de MU Online

Um erro de certificado SSL/TLS inválido é um dos problemas de infraestrutura mais visíveis (e mais prejudiciais à reputação) que um servidor privado de MU Online pode enfrentar: o jogador abre o site para criar conta ou acessar o painel e recebe um aviso vermelho de "conexão não é privada" ou "site inseguro". Além de assustar novos jogadores, isso pode bloquear completamente o cadastro em navegadores mais restritivos. Este tutorial cobre o diagnóstico da causa exata do erro, a correção via renovação/reemissão de certificado, e a configuração correta no Nginx e Apache para que isso não volte a acontecer.

Como o SSL/TLS funciona na prática do seu servidor

Quando um jogador acessa https://seusite.com, o navegador espera receber um certificado digital válido, emitido por uma Autoridade Certificadora (CA) reconhecida, que prove que o domínio é realmente controlado por quem diz ser. O certificado tem três elementos que geram erro se estiverem incorretos: validade (dentro do prazo), domínio (bate exatamente com o que está sendo acessado, incluindo www ou não) e cadeia de confiança (o certificado intermediário da CA está instalado corretamente no servidor).

Diagnosticando o tipo exato de erro

Antes de sair renovando certificado às cegas, identifique a mensagem exata — cada uma aponta para uma causa diferente:

Passo 1 — Verificar a validade e os detalhes do certificado atual

No navegador, clique no cadeado (ou no aviso de erro) → "Certificado" para ver a data de expiração e o domínio exato coberto. Via terminal, é mais rápido e confiável:

echo | openssl s_client -servername seusite.com -connect seusite.com:443 2>/dev/null | openssl x509 -noout -dates -subject

Isso retorna a data de início/expiração (notBefore/notAfter) e o subject (domínio para o qual o certificado foi emitido). Se o subject não bater exatamente com a URL acessada, esse é o problema.

Passo 2 — Corrigir certificado expirado com Let's Encrypt + Certbot

Para servidores rodando Nginx em Linux, a renovação/emissão via Certbot é o caminho mais direto:

sudo apt update && sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d seusite.com -d www.seusite.com

O Certbot detecta automaticamente os blocos server do Nginx, emite o certificado e ajusta a configuração para servir HTTPS. Para garantir que isso não expire de novo sem aviso, configure a renovação automática:

sudo systemctl enable certbot.timer
sudo systemctl start certbot.timer
sudo certbot renew --dry-run

O --dry-run simula a renovação sem aplicar de fato, confirmando que o processo automático vai funcionar quando o certificado estiver perto de expirar (Let's Encrypt renova automaticamente ~30 dias antes do vencimento).

Passo 3 — Corrigir domínio incompatível (Common Name Invalid)

Se o erro for ERR_CERT_COMMON_NAME_INVALID, o certificado foi emitido apenas para uma variação do domínio (ex.: só www.seusite.com, mas o jogador acessa seusite.com sem o www, ou vice-versa). A correção é reemitir incluindo todas as variações necessárias:

sudo certbot --nginx -d seusite.com -d www.seusite.com -d painel.seusite.com

Alternativamente, configure um redirecionamento permanente (301) da variante sem certificado para a que tem, evitando manter múltiplos domínios ativos desnecessariamente.

Passo 4 — Instalar corretamente a cadeia intermediária (Apache)

Em servidores Apache, um erro comum é instalar apenas o certificado do domínio (cert.pem) sem o certificado intermediário da CA (chain.pem ou fullchain.pem), gerando ERR_CERT_AUTHORITY_INVALID mesmo com certificado válido. A configuração correta no VirtualHost:

<VirtualHost *:443>
    ServerName seusite.com
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/seusite.com/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/seusite.com/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/seusite.com/chain.pem
</VirtualHost>

Usar o fullchain.pem (que já combina certificado + cadeia) no lugar de cert.pem + chain.pem separados é a abordagem mais simples e menos propensa a erro em versões recentes do Apache e Nginx.

Passo 5 — Configuração equivalente e mais robusta no Nginx

server {
    listen 443 ssl http2;
    server_name seusite.com www.seusite.com;

    ssl_certificate     /etc/letsencrypt/live/seusite.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/seusite.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

server {
    listen 80;
    server_name seusite.com www.seusite.com;
    return 301 https://$host$request_uri;
}

O segundo bloco garante que qualquer acesso via HTTP puro seja redirecionado automaticamente para HTTPS, evitando que o jogador acesse a versão insegura por engano.

Passo 6 — Corrigir conteúdo misto (mixed content)

Se o cadeado aparece "quebrado" mesmo com certificado válido, o problema costuma ser conteúdo misto: a página é carregada via HTTPS, mas referencia imagens, scripts ou fontes via http:// explícito. A correção é trocar todas as URLs absolutas hardcoded no HTML/CSS/JS para protocolo relativo ou HTTPS explícito:

<!-- Errado -->
<script src="http://seusite.com/assets/launcher.js"></script>

<!-- Correto -->
<script src="https://seusite.com/assets/launcher.js"></script>

Ferramentas como o DevTools do navegador (aba Console/Security) listam exatamente quais recursos estão sendo bloqueados por conteúdo misto.

Passo 7 — Cobrir subdomínios usados pelo launcher e API

Se o launcher consome uma API em api.seusite.com ou painel.seusite.com, cada subdomínio precisa do seu próprio certificado válido (ou um wildcard cobrindo todos). Para simplificar a manutenção com múltiplos subdomínios:

sudo certbot --nginx -d seusite.com -d www.seusite.com -d api.seusite.com -d painel.seusite.com

Ou, para um wildcard (requer validação DNS, não HTTP):

sudo certbot certonly --manual --preferred-challenges dns -d "*.seusite.com" -d seusite.com

Monitoramento contínuo de expiração

Não confie apenas na renovação automática — configure um alerta externo. Serviços gratuitos como UptimeRobot ou um script simples de cron que roda o comando openssl do Passo 1 semanalmente e envia alerta ao Discord da equipe caso a expiração esteja a menos de 15 dias evitam surpresas.

Erros comuns e soluções

Checklist de saúde do SSL/TLS

• Certificado válido e com data de expiração confirmada via openssl.
• Domínio do certificado cobre todas as variantes acessadas (www e sem www).
• Cadeia intermediária instalada corretamente (fullchain.pem).
• Renovação automática configurada e testada com --dry-run.
• Redirecionamento HTTP → HTTPS ativo em todos os domínios.
• Nenhum conteúdo misto (recursos HTTP) na página servida via HTTPS.
• Subdomínios do launcher/API cobertos por certificado válido.
• Monitoramento externo de expiração configurado.

Com o SSL do site e do launcher estabilizado, vale revisar a segurança geral da sua infraestrutura — firewall, portas expostas e backup do banco — para fechar as brechas mais comuns de um servidor privado. Se ainda não tem a base do servidor documentada, comece pelo guia de criação de servidor de MU Online.

Perguntas frequentes