Cómo configurar SSL/HTTPS en el sitio del servidor de MU Online

Ejecutar el sitio de tu servidor de MU Online en HTTP puro, sin candado, es un problema en varios frentes al mismo tiempo. Primero, credibilidad: el navegador muestra "No seguro" junto a la dirección, y ningún jugador confía en escribir su contraseña en ese contexto. Segundo, seguridad real: sin HTTPS, el login, el registro y los datos del panel viajan en texto plano, y cualquier persona en la misma red (Wi-Fi de cibercafé, proveedor, router comprometido) puede capturar las credenciales. Tercero, funcionalidad: recursos modernos de sitios web, integraciones de pago e incluso el posicionamiento en buscadores dependen de HTTPS.

Esta guía es de nivel intermedio y cubre los dos entornos más usados en servidores de MU: IIS en Windows Server (estándar de quienes usan webEngineNET y distros que corren sobre Windows) y Apache (XAMPP en Windows o LAMP en Linux). Vas a instalar un certificado gratuito y válido, forzar HTTPS, automatizar la renovación y resolver los errores clásicos que aparecen justo después de activarlo. Si aún estás armando la base del servidor, mira antes cómo crear un servidor de MU Online.

Requisitos previos

Antes de empezar, confirma que tienes todo esto listo:

• Un dominio propio (ej.: miservidor.com) — no puedes tener un certificado público válido solo con IP.
• DNS apuntado: un registro A del dominio (y del www) apuntando a la IP del servidor, ya propagado.
• Acceso administrativo al servidor (RDP en Windows Server o SSH en Linux).
• Sitio funcionando en HTTP (puerto 80) antes de tocar el SSL.
• Puertos 80 y 443 liberados en el firewall del sistema operativo y en el panel del proveedor/VPS.
• Un horario de bajo movimiento para hacer el cambio, ya que el sitio puede oscilar por algunos minutos.

> Aviso: el puerto 80 debe estar abierto durante la emisión del certificado. Let's Encrypt valida el dominio accediendo a un archivo temporal vía HTTP. Si el 80 está cerrado, la emisión falla.

Entendiendo lo básico: certificado, CA y puertos

Antes de instalar, vale la pena fijar tres conceptos que evitan la mayoría de los errores:

La diferencia práctica entre un certificado Let's Encrypt (gratuito, válido, aceptado por todos los navegadores) y uno autofirmado (que tú mismo generas) es enorme: el autofirmado cifra, pero el navegador muestra pantalla roja de "conexión no privada". Para un servidor público, usa siempre una CA reconocida. El autofirmado solo sirve para entorno interno de pruebas.

Opción A — HTTPS en IIS (Windows Server) con win-acme

El win-acme (wacs.exe) es la herramienta estándar para Let's Encrypt en IIS. Emite, instala y configura el binding automáticamente.

Paso 1 — Preparar el entorno

1. Accede al servidor vía RDP como administrador.
2. Confirma que el sitio ya responde en http://miservidor.com.
3. Abre el PowerShell como administrador y crea la carpeta de trabajo:

New-Item -ItemType Directory -Force C:\ssl-tools | Out-Null
Set-Location C:\ssl-tools

Paso 2 — Liberar los puertos en el firewall

New-NetFirewallRule -DisplayName "HTTP-80"  -Direction Inbound -Protocol TCP -LocalPort 80  -Action Allow
New-NetFirewallRule -DisplayName "HTTPS-443" -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow

Paso 3 — Descargar y ejecutar el win-acme

1. Descarga el win-acme (versión x64) del repositorio oficial en https://github.com/win-acme/win-acme/releases.
2. Extráelo en C:\ssl-tools\wacs\.
3. Ejecuta el wacs.exe como administrador.
4. En el menú, elige la opción de crear un certificado nuevo simple (normalmente la tecla N).
5. El win-acme lista los sitios del IIS. Selecciona el sitio de tu MU.
6. Elige los hostnames (miservidor.com y www.miservidor.com).
7. Acepta los términos de Let's Encrypt e informa un correo para avisos de expiración.

El win-acme valida el dominio, emite el certificado, crea el binding HTTPS en el puerto 443 en IIS y ya configura una tarea programada de renovación. Al final, https://miservidor.com debe abrir con candado.

Paso 4 — Revisar el binding en IIS

Abre el IIS Manager → Sites → tu sitio → Bindings. Debe existir una entrada https en el puerto 443 con el certificado del dominio. Si no existe, agrégala manualmente: Add → Type: https → Port: 443 → SSL certificate: el de tu dominio.

Paso 5 — Forzar HTTPS vía web.config

Agrega (o edita) el web.config en la raíz del sitio para redirigir todo HTTP a HTTPS. Requiere el módulo URL Rewrite instalado en IIS.

<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Forcar HTTPS" stopProcessing="true">
          <match url="(.*)" />
          <conditions>
            <add input="{HTTPS}" pattern="off" ignoreCase="true" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}/{R:1}"
                  redirectType="Permanent" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

Opción B — HTTPS en Apache (XAMPP / Linux)

Si usas Apache, el camino depende del sistema. En Linux el certbot hace casi todo solo; en XAMPP (Windows) la configuración es más manual.

Paso 1 (Linux) — Emitir con certbot

# Debian/Ubuntu con Apache
sudo apt update && sudo apt install certbot python3-certbot-apache -y
sudo certbot --apache -d miservidor.com -d www.miservidor.com

El certbot pregunta el correo, valida el dominio, escribe el VirtualHost SSL y ofrece redirigir HTTP a HTTPS automáticamente — acepta esa opción. La renovación ya queda programada vía systemd timer o cron.

Paso 2 (XAMPP/Windows) — Activar el módulo SSL

En XAMPP, el SSL ya viene compilado. Confirma en el httpd.conf que estas líneas están descomentadas:

LoadModule ssl_module modules/mod_ssl.so
Include conf/extra/httpd-ssl.conf

Después, en el httpd-ssl.conf, apunta a los archivos del certificado (que recibiste de la CA o generaste):

<VirtualHost _default_:443>
    DocumentRoot "C:/xampp/htdocs"
    ServerName miservidor.com:443
    SSLEngine on
    SSLCertificateFile      "conf/ssl.crt/miservidor.crt"
    SSLCertificateKeyFile   "conf/ssl.key/miservidor.key"
    SSLCertificateChainFile "conf/ssl.crt/cadena.crt"
</VirtualHost>

Paso 3 — Forzar HTTPS vía .htaccess

En la raíz del sitio (htdocs), con mod_rewrite activo:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [L,R=301]

Reinicia Apache desde el panel de XAMPP (o sudo systemctl restart apache2 en Linux) y prueba https://miservidor.com.

Renovación automática — el paso que nadie puede saltarse

El certificado Let's Encrypt expira en 90 días. Si expira, todo el sitio pasa a mostrar error de seguridad y los jugadores desaparecen. La renovación automática ya la configuran el win-acme y el certbot, pero debes verificar que funciona:

# Windows: revisar la tarea programada del win-acme
Get-ScheduledTask | Where-Object { $_.TaskName -like "*win-acme*" }

# Linux: probar la renovación en modo simulación (no cambia nada)
sudo certbot renew --dry-run

Si el --dry-run termina sin error, la renovación real va a funcionar. Anota en el calendario un recordatorio trimestral solo para revisar el candado, por si acaso.

Corrigiendo el contenido mixto (mixed content)

El error más común después de activar HTTPS: el candado aparece "roto" o la consola muestra avisos de mixed content. Esto ocurre cuando una página https:// carga recursos por http:// — imágenes, banners de ranking, CSS o scripts. El navegador bloquea parte de esos recursos y reclama.

Solución: cambia todas las URLs internas a HTTPS o, mejor, a rutas relativas:

<!-- Incorrecto: fuerza http dentro de una página https -->
<img src="http://miservidor.com/img/logo.png">

<!-- Correcto: ruta relativa, hereda el protocolo de la página -->
<img src="/img/logo.png">

Para encontrar las ocurrencias rápidamente, usa la búsqueda del editor por http:// en todos los archivos del sitio y ajusta. No olvides revisar también los campos de configuración guardados en la base (URLs de banner, enlaces del panel).

Errores comunes y soluciones

Endureciendo la configuración (opcional, recomendado)

Después de que el HTTPS esté estable por algunos días, activa el HSTS para que el navegador nunca más intente HTTP en tu dominio. En IIS, agrega el header en el web.config; en Apache, en el VirtualHost SSL:

# Apache — dentro del VirtualHost 443
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Cuidado: solo activa HSTS cuando tengas la certeza de que todo funciona en HTTPS, incluidos los subdominios. Una vez que el navegador memoriza el HSTS, rechaza cualquier acceso HTTP a ese dominio por el tiempo del max-age. Empieza con un valor menor (por ejemplo, algunas horas) mientras pruebas.

Lista de verificación de lanzamiento

• Dominio con registro A apuntado y propagado a la IP del servidor
• Puertos 80 y 443 liberados en el firewall del SO y del proveedor
• Certificado válido de una CA reconocida instalado (no autofirmado)
• Binding HTTPS en el puerto 443 configurado (IIS) o VirtualHost 443 (Apache)
• Redirección 301 de HTTP a HTTPS activa
• Renovación automática verificada (win-acme o certbot renew --dry-run)
• Ningún aviso de mixed content en la consola del navegador
• Login y registro probados y funcionando bajo HTTPS
• URLs internas y de la base convertidas a https/relativas
• HSTS evaluado y activado tras un período de estabilización
• Recordatorio trimestral creado para revisar el candado

Con HTTPS activo, forzado y con renovación automática, el sitio de tu servidor pasa a proteger de verdad las credenciales de los jugadores y gana la credibilidad que el candado transmite. Es un paso pequeño en esfuerzo y enorme en confianza.

Preguntas frecuentes