Cómo resolver el error de certificado SSL inválido en el sitio y launcher de tu servidor de MU Online

Un error de certificado SSL/TLS inválido es uno de los problemas de infraestructura más visibles (y más perjudiciales para la reputación) que un servidor privado de MU Online puede enfrentar: el jugador abre el sitio para crear una cuenta o acceder al panel y recibe un aviso rojo de "la conexión no es privada" o "sitio inseguro". Además de asustar a jugadores nuevos, esto puede bloquear por completo el registro en navegadores más restrictivos. Este tutorial cubre el diagnóstico de la causa exacta del error, la corrección vía renovación/reemisión de certificado, y la configuración correcta en Nginx y Apache para que esto no vuelva a ocurrir.

Cómo funciona el SSL/TLS en la práctica de tu servidor

Cuando un jugador accede a https://tusitio.com, el navegador espera recibir un certificado digital válido, emitido por una Autoridad Certificadora (CA) reconocida, que demuestre que el dominio realmente es controlado por quien dice serlo. El certificado tiene tres elementos que generan error si están incorrectos: validez (dentro del plazo), dominio (coincide exactamente con lo que se está accediendo, incluyendo www o no) y cadena de confianza (el certificado intermedio de la CA está instalado correctamente en el servidor).

Diagnosticando el tipo exacto de error

Antes de salir a renovar el certificado a ciegas, identifica el mensaje exacto — cada uno apunta a una causa diferente:

Paso 1 — Verificar la validez y los detalles del certificado actual

En el navegador, haz clic en el candado (o en el aviso de error) → "Certificado" para ver la fecha de expiración y el dominio exacto cubierto. Vía terminal, es más rápido y confiable:

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

Esto devuelve la fecha de inicio/expiración (notBefore/notAfter) y el subject (dominio para el cual se emitió el certificado). Si el subject no coincide exactamente con la URL accedida, ese es el problema.

Paso 2 — Corregir un certificado expirado con Let's Encrypt + Certbot

Para servidores que corren Nginx en Linux, la renovación/emisión vía Certbot es el camino más directo:

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

Certbot detecta automáticamente los bloques server de Nginx, emite el certificado y ajusta la configuración para servir HTTPS. Para garantizar que esto no expire de nuevo sin aviso, configura la renovación automática:

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

El --dry-run simula la renovación sin aplicarla realmente, confirmando que el proceso automático funcionará cuando el certificado esté por vencer (Let's Encrypt renueva automáticamente ~30 días antes del vencimiento).

Paso 3 — Corregir dominio incompatible (Common Name Invalid)

Si el error es ERR_CERT_COMMON_NAME_INVALID, el certificado fue emitido solo para una variante del dominio (ej.: solo www.tusitio.com, pero el jugador accede a tusitio.com sin el www, o viceversa). La corrección es reemitir incluyendo todas las variantes necesarias:

sudo certbot --nginx -d tusitio.com -d www.tusitio.com -d panel.tusitio.com

Alternativamente, configura una redirección permanente (301) de la variante sin certificado hacia la que sí lo tiene, evitando mantener múltiples dominios activos innecesariamente.

Paso 4 — Instalar correctamente la cadena intermedia (Apache)

En servidores Apache, un error común es instalar solo el certificado del dominio (cert.pem) sin el certificado intermedio de la CA (chain.pem o fullchain.pem), generando ERR_CERT_AUTHORITY_INVALID incluso con un certificado válido. La configuración correcta en el VirtualHost:

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

Usar el fullchain.pem (que ya combina certificado + cadena) en lugar de cert.pem + chain.pem por separado es el enfoque más simple y menos propenso a errores en versiones recientes de Apache y Nginx.

Paso 5 — Configuración equivalente y más robusta en Nginx

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

    ssl_certificate     /etc/letsencrypt/live/tusitio.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/tusitio.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 tusitio.com www.tusitio.com;
    return 301 https://$host$request_uri;
}

El segundo bloque garantiza que cualquier acceso vía HTTP puro sea redirigido automáticamente a HTTPS, evitando que el jugador acceda por error a la versión insegura.

Paso 6 — Corregir contenido mixto (mixed content)

Si el candado aparece "roto" incluso con un certificado válido, el problema suele ser contenido mixto: la página se carga vía HTTPS, pero referencia imágenes, scripts o fuentes vía http:// explícito. La corrección es cambiar todas las URLs absolutas hardcodeadas en el HTML/CSS/JS a protocolo relativo o HTTPS explícito:

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

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

Herramientas como el DevTools del navegador (pestaña Console/Security) listan exactamente qué recursos están siendo bloqueados por contenido mixto.

Paso 7 — Cubrir los subdominios usados por el launcher y la API

Si el launcher consume una API en api.tusitio.com o panel.tusitio.com, cada subdominio necesita su propio certificado válido (o un wildcard que los cubra a todos). Para simplificar el mantenimiento con múltiples subdominios:

sudo certbot --nginx -d tusitio.com -d www.tusitio.com -d api.tusitio.com -d panel.tusitio.com

O, para un wildcard (requiere validación DNS, no HTTP):

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

Monitoreo continuo de expiración

No confíes solo en la renovación automática — configura una alerta externa. Servicios gratuitos como UptimeRobot o un script simple de cron que ejecute el comando openssl del Paso 1 semanalmente y envíe una alerta al Discord del equipo si la expiración está a menos de 15 días evitan sorpresas.

Errores comunes y soluciones

Lista de verificación de salud del SSL/TLS

• Certificado válido y con fecha de expiración confirmada vía openssl.
• El dominio del certificado cubre todas las variantes accedidas (www y sin www).
• Cadena intermedia instalada correctamente (fullchain.pem).
• Renovación automática configurada y probada con --dry-run.
• Redirección HTTP → HTTPS activa en todos los dominios.
• Ningún contenido mixto (recursos HTTP) en la página servida vía HTTPS.
• Subdominios del launcher/API cubiertos por certificado válido.
• Monitoreo externo de expiración configurado.

Con el SSL del sitio y del launcher estabilizado, vale la pena revisar la seguridad general de tu infraestructura —firewall, puertos expuestos y backup de la base de datos— para cerrar las brechas más comunes de un servidor privado. Si aún no tienes la base del servidor documentada, empieza por la guía de creación de servidor de MU Online.

Preguntas frecuentes