Cómo automatizar la renovación del certificado SSL del sitio de tu servidor de MU Online
Configura Certbot con Let's Encrypt para renovar automáticamente el certificado SSL del sitio, panel de cuenta y tienda de tu servidor de MU Online, evitando caídas de HTTPS y alertas de sitio inseguro.
Un certificado SSL vencido es uno de los incidentes más evitables — y más perjudiciales para la imagen — que puede sufrir un servidor de MU Online: de un día para el otro, el sitio, el panel de cuenta y la tienda empiezan a mostrar "conexión no segura" en el navegador, alejando jugadores y bloqueand
Un certificado SSL vencido es uno de los incidentes más evitables — y más perjudiciales para la imagen — que puede sufrir un servidor de MU Online: de un día para el otro, el sitio, el panel de cuenta y la tienda empiezan a mostrar "conexión no segura" en el navegador, alejando jugadores y bloqueando pagos. La causa casi siempre es la misma: el certificado se emitió manualmente una vez y nadie configuró la renovación automática. Este tutorial muestra cómo usar Certbot con Let's Encrypt para emitir y renovar certificados automáticamente, cubriendo Nginx, Apache y la alternativa para Windows/IIS, además de las pruebas y alertas que garantizan que esto nunca más vuelva a ser un problema.
Por qué HTTPS es obligatorio para el sitio del servidor
Además del candado en el navegador, HTTPS protege credenciales de login, datos de pago en la tienda de ítems y cookies de sesión contra la interceptación. Los navegadores modernos (Chrome, Firefox, Edge) bloquean o alertan agresivamente sitios sin HTTPS, y los motores de búsqueda penalizan el ranking de páginas sin certificado válido — para un servidor que depende de la difusión orgánica, esto tiene un impacto directo en los nuevos registros.
Entendiendo el ciclo de vida del certificado de Let's Encrypt
A diferencia de los certificados comerciales tradicionales (que pueden durar de 1 a 2 años), los certificados de Let's Encrypt tienen una validez de 90 días, por diseño — esto reduce el riesgo de uso indebido de certificados olvidados y obliga a la existencia de automatización. La expectativa del propio Let's Encrypt es que la renovación sea automática; renovar manualmente cada 3 meses es el tipo de tarea que cualquier equipo termina olvidando.
| Hito | Acción esperada |
|---|---|
| Día 0 | Certificado emitido |
| Día 60 | Certbot ya intenta renovar automáticamente (30 días antes del vencimiento) |
| Día 90 | Vencimiento — nunca debería alcanzarse sin renovación previa |
Instalando Certbot en el servidor (Linux + Nginx)
En distribuciones basadas en Debian/Ubuntu, la instalación vía snap es la recomendada oficialmente por mantener a Certbot siempre actualizado:
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/certbotEmitiendo el certificado para el dominio del servidor
Con Nginx ya configurado y respondiendo en el puerto 80 para el dominio (por ejemplo, miservidor.com y www.miservidor.com), la emisión es interactiva y también se encarga de la configuración del bloque HTTPS:
sudo certbot --nginx -d miservidor.com -d www.miservidor.com -d tienda.miservidor.comCertbot detecta los bloques server existentes en Nginx, agrega automáticamente las directivas listen 443 ssl y las rutas de los archivos de certificado, y ofrece redirigir todo el tráfico HTTP a HTTPS — aceptá esa opción, es la práctica recomendada.
Configuración equivalente para Apache
Si el sitio del servidor corre en Apache en vez de Nginx, el plugin correspondiente sigue la misma lógica:
sudo apt install -y python3-certbot-apache
sudo certbot --apache -d miservidor.com -d www.miservidor.comVerificando la renovación automática (systemd timer)
Las instalaciones modernas de Certbot ya registran un systemd timer que corre dos veces al día verificando certificados cerca del vencimiento. Confirmá que esté activo:
systemctl status certbot.timer
sudo certbot renew --dry-runEl --dry-run simula el proceso completo de renovación sin reemplazar realmente el certificado — si termina sin error, la automatización está funcionando correctamente.
Alternativa vía cron (sistemas sin systemd timer)
En entornos más antiguos donde el timer no se instala automáticamente, agregá la entrada de cron manualmente:
0 3,15 * * * /usr/bin/certbot renew --quiet --deploy-hook "systemctl reload nginx"Correrlo dos veces al día (03h y 15h) es la práctica recomendada por la propia documentación de Let's Encrypt, ya que distribuye la carga de los servidores de validación y aumenta la probabilidad de éxito incluso si un intento falla por una inestabilidad momentánea de red.
El hook de deploy: recargando el servidor web sin downtime
El flag --deploy-hook ejecuta un comando solo cuando la renovación realmente ocurre (no en cada verificación), garantizando que el nuevo certificado se cargue sin necesidad de tumbar el sitio:
sudo certbot renew --deploy-hook "systemctl reload nginx"Un reload (no un restart) es suficiente para que Nginx/Apache carguen el certificado nuevo, manteniendo activas las conexiones existentes — el jugador navegando en el sitio no nota nada.
Certificado wildcard para subdominios (panel, tienda, foro)
Los servidores de MU suelen tener varios subdominios (panel., tienda., foro., api.). En vez de emitir un certificado por subdominio, un certificado wildcard (*.miservidor.com) cubre todos de una vez, pero exige validación vía DNS (registro TXT), no vía HTTP:
sudo certbot certonly --manual --preferred-challenges dns \
-d miservidor.com -d "*.miservidor.com"Para automatizar totalmente el wildcard (sin intervención manual en cada renovación), usá un plugin de DNS específico de tu proveedor (Cloudflare, Route53, etc.), que inserta y elimina el registro TXT automáticamente vía API.
Automatizando el wildcard con Cloudflare (ejemplo)
Si el dominio del servidor está en Cloudflare, el plugin certbot-dns-cloudflare elimina el paso manual del desafío DNS:
sudo apt install -y python3-certbot-dns-cloudflare# /etc/letsencrypt/cloudflare.ini
dns_cloudflare_api_token = TU_TOKEN_AQUIchmod 600 /etc/letsencrypt/cloudflare.ini
sudo certbot certonly --dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
-d miservidor.com -d "*.miservidor.com"Con esto, incluso el certificado wildcard se renueva solo mediante el systemd timer, sin ningún clic manual cada 90 días.
Alertando antes del vencimiento (capa extra de seguridad)
Aun con automatización, es prudente tener una alerta independiente monitoreando la fecha de expiración real del certificado en producción, por si la renovación falla en silencio por cualquier motivo (límite de tasa, DNS caído, etc.):
DIAS_RESTANTES=$(echo | openssl s_client -servername miservidor.com -connect miservidor.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\":\"⚠️ ¡El certificado SSL vence en $DIAS_RESTANTES días!\"}"
fiErrores comunes y soluciones
| Síntoma | Causa probable | Solución |
|---|---|---|
| El navegador muestra "conexión no segura" | El certificado venció sin renovarse | Ejecutá certbot renew manualmente e investigá por qué falló la automatización |
certbot renew --dry-run falla | Puerto 80 bloqueado por firewall | Liberá el puerto 80 para el desafío HTTP-01 de Let's Encrypt |
| La renovación del wildcard no se automatiza | Validación DNS manual sin plugin de API | Configurá el plugin certbot-dns-<proveedor> correspondiente |
| El sitio queda caído después de la renovación | Falta el deploy-hook, la config no se recarga | Agregá --deploy-hook "systemctl reload nginx" |
| Se alcanzó el límite de tasa de Let's Encrypt | Muchas emisiones repetidas en poco tiempo | Usá --dry-run para pruebas; emití de verdad solo cuando sea necesario |
| Certificado emitido pero el subdominio nuevo no queda cubierto | Subdominio no incluido en los -d al emitir | Reemití incluyendo todos los subdominios o usá wildcard |
Lista de verificación de SSL automatizado
- Certbot instalado y certificado emitido para todos los dominios/subdominios activos.
- Redirección HTTP → HTTPS confirmada en Nginx/Apache.
certbot renew --dry-runejecutado sin errores.systemd timero cron de renovación confirmado activo.- Deploy-hook de reload del servidor web configurado.
- Wildcard configurado vía plugin de DNS, si aplica.
- Alerta independiente de expiración (openssl + webhook) implementada.
Con la renovación de SSL totalmente automatizada, el sitio, el panel de cuenta y la tienda del servidor dejan de correr el riesgo de aparecer como "inseguros" ante los jugadores. Si todavía estás estructurando el entorno web desde cero, mirá también el tutorial de creación de servidor de MU Online para alinear la infraestructura del sitio con la del GameServer.
Preguntas frecuentes
¿El certificado de Let's Encrypt es realmente gratuito para siempre?
Sí, Let's Encrypt es un servicio gratuito y sin fines de lucro mantenido por la Internet Security Research Group. No hay costo por emitir o renovar certificados, siempre que la renovación automática esté configurada — el certificado vence cada 90 días y debe renovarse antes de eso.
¿Qué pasa si el certificado vence sin que me dé cuenta?
El navegador del jugador empieza a mostrar un aviso de 'conexión no segura' al acceder al sitio, panel de cuenta o tienda, lo que reduce drásticamente la confianza y las conversiones de venta. Los formularios de login y pago pueden dejar de funcionar en navegadores más restrictivos.
¿Necesito renovar manualmente cada 90 días?
No, si la automatización está configurada correctamente. Certbot instala por defecto una tarea (cron o systemd timer) que verifica diariamente si el certificado está a menos de 30 días del vencimiento y lo renueva automáticamente cuando es necesario.
¿Funciona con cualquier servidor web (Nginx, Apache, IIS)?
Certbot tiene soporte nativo para Nginx y Apache en Linux. Para IIS en Windows, la alternativa más usada es win-acme (también basado en Let's Encrypt) con una programación equivalente vía el Programador de Tareas.
¿Necesito reiniciar el sitio cada vez que el certificado se renueva?
Depende del servidor web. Nginx y Apache normalmente solo necesitan un reload (no un reinicio completo) para cargar el nuevo certificado, algo que Certbot ya hace automáticamente vía un hook posterior a la renovación, sin downtime perceptible.