Tener un certificado SSL instalado no es lo mismo que tener Moodle correctamente configurado en HTTPS. Es habitual encontrar instalaciones con el candado verde en la barra del navegador, pero con recursos internos cargando todavía por HTTP, avisos de “contenido no seguro” en algunas páginas, o certificados a punto de caducar sin que nadie lo haya notado.
En esta guía vas a ver qué implica configurar SSL/HTTPS correctamente en Moodle, más allá de simplemente instalar el certificado.
Por qué HTTPS es innegociable en una plataforma educativa
Moodle gestiona credenciales de acceso, calificaciones, comunicaciones privadas entre tutor y alumno, y en el caso de formación bonificada, información que forma parte de la trazabilidad exigida por FUNDAE. Transmitir cualquiera de estos datos sin cifrar expone tanto a los usuarios como al propio centro a riesgos de interceptación, además de generar advertencias de seguridad visibles en el navegador que dañan la confianza de quien accede.
Configuración base en Moodle
1. Instala un certificado SSL válido
Puede ser un certificado gratuito (Let’s Encrypt) o de pago, según las necesidades de tu proyecto. Lo importante no es el origen del certificado, sino que esté correctamente instalado, sin errores de cadena de confianza, y con renovación automática configurada si usas Let’s Encrypt, para evitar caducidades no vigiladas.
Let’s Encrypt emite certificados con validez de 90 días, un plazo corto pensado precisamente para que la renovación sea automática y no manual. Ahí está la clave: si dependes de renovarlo a mano cada tres meses, tarde o temprano se te pasa. La renovación desatendida es lo que evita que el HTTPS se caiga de golpe un lunes cualquiera.
Cómo se resuelve según cómo tengas montado el servidor:
- Panel de hosting (cPanel, Plesk, DirectAdmin): casi todos incluyen un emisor automático (AutoSSL en cPanel, el Let’s Encrypt de Plesk) que renueva y reinstala el certificado solo. Si tu Moodle vive en uno de estos paneles, normalmente ya está cubierto; solo tienes que confirmar que el dominio del Moodle está incluido en la cobertura y que no hay un certificado de pago antiguo pisando al automático.
- Servidor propio con Certbot: la renovación la hace un temporizador de systemd o un cron que Certbot instala al configurarse. Puedes comprobar que está vivo y probar la renovación sin llegar a emitir nada:
# ¿está activo el temporizador de renovación?
systemctl list-timers | grep certbot
# simula la renovación sin tocar el certificado real (dry-run)
sudo certbot renew --dry-runSi el --dry-run termina con “Congratulations, all simulations of the renewal succeeded”, la renovación real funcionará el día que toque. Si falla ahí, mejor descubrirlo ahora que el día de la caducidad. Tras cualquier renovación, el servidor web (Apache, Nginx o LiteSpeed) tiene que recargar la configuración para servir el certificado nuevo; Certbot suele encargarse con un hook, pero conviene verificar que el reload está ocurriendo de verdad.
2. Configura $CFG->wwwroot con https://
En el archivo config.php de Moodle, la variable $CFG->wwwroot debe usar el prefijo https://, no http://. Esto le indica a Moodle que debe generar todos los enlaces internos, redirecciones y referencias a recursos usando HTTPS de forma consistente. Este es el ajuste maestro: Moodle construye cada URL del sitio a partir de wwwroot, así que si aquí pone http://, no hay redirección de servidor que arregle del todo el problema.
<?php // config.php
$CFG->wwwroot = 'https://tu-dominio.com';Un aviso importante: wwwroot no admite doble entrada. Si tienes el sitio accesible por www.tu-dominio.com y por tu-dominio.com, elige una forma canónica en wwwroot y redirige la otra a nivel de servidor. Acceder por la variante que no coincide con wwwroot provoca cierres de sesión y avisos de “URL no válida”.
2 bis. $CFG->sslproxy cuando Moodle está detrás de un proxy o balanceador
Este es uno de los fallos que más entran por soporte y casi nadie diagnostica a la primera. Si tu Moodle está detrás de un balanceador de carga, un CDN (Cloudflare), un proxy inverso (Nginx delante de Apache) o cualquier capa que termina el TLS antes de llegar a Moodle, el servidor de aplicaciones recibe la petición por HTTP interno aunque el usuario navegue por HTTPS. Moodle detecta “esto viene por HTTP” y, como wwwroot es HTTPS, redirige a HTTPS. El proxy vuelve a entregar por HTTP. Moodle redirige otra vez. Resultado: un bucle de redirección infinito (ERR_TOO_MANY_REDIRECTS) que deja el sitio inaccesible.
La solución es decirle a Moodle que confíe en que el TLS ya se terminó antes, con una sola línea en config.php:
<?php // config.php — solo si hay proxy/balanceador que termina el TLS
$CFG->wwwroot = 'https://tu-dominio.com';
$CFG->sslproxy = true;Con sslproxy = true, Moodle asume que la conexión externa es segura y deja de forzar la redirección interna, rompiendo el bucle. La regla práctica: si el TLS lo termina el propio servidor donde corre Moodle, no pongas sslproxy; si lo termina una capa por delante, ponlo. Activarlo cuando no hay proxy es igual de problemático que no activarlo cuando sí lo hay.
3. Fuerza HTTPS en todo el sitio
Más allá de configurar wwwroot, activa la opción de forzar HTTPS en Site administration > Security > HTTP security, marcando la opción de usar HTTPS para todo el sitio (Use HTTPS for logins, o el ajuste equivalente según la versión), en vez de dejarlo solo para el formulario de login.
4. Configura una redirección permanente de HTTP a HTTPS
A nivel de servidor web (Apache o Nginx), añade una redirección 301 permanente de cualquier petición HTTP hacia su equivalente HTTPS, para que nadie pueda acceder accidentalmente a la versión sin cifrar del sitio.
5. Cookies seguras y HSTS
Forzar HTTPS y no proteger las cookies deja la puerta entreabierta. Con la conexión ya cifrada, activa las cookies seguras para que el navegador nunca envíe la cookie de sesión por HTTP. En Moodle es un ajuste directo en config.php (o en Site administration > Security > HTTP security):
<?php // config.php
$CFG->cookiesecure = true;Con cookiesecure = true, la cookie de sesión de Moodle solo viaja por conexiones cifradas. Si wwwroot es HTTPS, este ajuste debería estar activo siempre; dejarlo desactivado expone la sesión a robo por interceptación aunque el resto del sitio esté en HTTPS. Es una de las casillas que repasamos en el checklist de hardening de Moodle, junto al resto de ajustes de seguridad del sitio.
El siguiente escalón es HSTS (Strict-Transport-Security), una cabecera que se configura a nivel de servidor web y que le dice al navegador: “para este dominio, usa HTTPS siempre, ni te molestes en probar HTTP”. Una vez el navegador la recibe, ignora cualquier intento de acceso por HTTP durante el tiempo indicado, incluso antes de contactar con el servidor. Es una capa fuerte, pero por eso mismo hay que activarla cuando ya estás seguro de que todo el sitio y sus subdominios sirven bien por HTTPS: si activas HSTS y luego un subdominio se queda sin certificado válido, quedará inaccesible hasta que caduque la política en el navegador del usuario. Empieza con un max-age corto, verifica que nada se rompe, y súbelo después.
El problema del contenido mixto
El error más habitual tras migrar a HTTPS no es la configuración del certificado en sí, sino el contenido mixto: recursos (imágenes, scripts, hojas de estilo) que siguen cargando por HTTP dentro de una página servida por HTTPS. Los navegadores modernos bloquean o marcan como inseguro este tipo de contenido, generando advertencias visibles a los usuarios aunque el sitio en general esté bien configurado.
Las causas más comunes de contenido mixto en Moodle:
- URLs absolutas con
http://hardcodeadas en contenido de curso creado antes de migrar a HTTPS. - Plugins de terceros que generan enlaces o cargan recursos externos sin respetar el protocolo de la página actual.
- Contenido embebido (vídeos, iframes) de servicios externos que aún se referencian con
http://en vez dehttps://o de una URL relativa al protocolo.
Conviene distinguir dos gravedades. El contenido mixto pasivo (imágenes, vídeos, audio cargados por HTTP) el navegador suele cargarlo pero marca el candado como “no del todo seguro”. El contenido mixto activo (scripts, hojas de estilo, iframes cargados por HTTP) el navegador directamente lo bloquea, y ahí es donde una página se rompe: un banco de preguntas que no carga, un editor que se queda a medias, un recurso incrustado que aparece en blanco.
Esta tabla resume las causas reales que vemos entrar por soporte, cómo cazarlas y cómo cerrarlas:
| Causa | Cómo detectarla | Cómo arreglarla |
|---|---|---|
URLs http:// absolutas escritas a mano en contenido de curso (etiquetas, páginas, descripciones) | Consola del navegador → aviso “Mixed Content” apuntando al recurso; o buscar http:// en la base de datos | Buscar/reemplazar masivo de http://tu-dominio por https://tu-dominio en la BD, o reescribir el recurso a URL relativa al protocolo (//) |
Enlaces incrustados vía wwwroot antiguo (contenido creado antes de migrar a HTTPS) | Los enlaces internos apuntan a http:// aunque wwwroot ya sea HTTPS | Corregir wwwroot a HTTPS regenera los nuevos; los ya guardados en la BD requieren búsqueda/reemplazo |
| Plugins de terceros que construyen URLs ignorando el protocolo de la página | El recurso mixto viene de una ruta de /mod/ o /blocks/ de un plugin concreto | Actualizar el plugin; si persiste, revisar su config o reportarlo; comprobar si respeta sslproxy |
Embebidos externos (YouTube, Vimeo, mapas, widgets) referenciados por http:// | La URL bloqueada es de un dominio externo, no del tuyo | Reemplazar el embebido por su versión https:// o por URL relativa al protocolo |
Falta sslproxy con Moodle tras un proxy | Enlaces y assets generados en http:// pese a wwwroot HTTPS, o candado inestable | Añadir $CFG->sslproxy = true; en config.php (ver arriba) |
Cómo detectar y corregir contenido mixto
El orden que funciona es primero medir, luego corregir, y por último verificar que no queda nada:
- Consola del navegador: abre las herramientas de desarrollador (F12) → pestaña Console en varias páginas representativas (portada, un curso, la vista de un recurso, un cuestionario). Los avisos de “Mixed Content” indican la URL exacta del recurso inseguro, lo que te dice de dónde sale el problema.
- Escaneo del sitio: para no ir página por página, un escáner de contenido mixto (extensiones de navegador o servicios online que rastrean el sitio) recorre muchas URLs y lista todos los recursos servidos por HTTP de una vez.
- Búsqueda en la base de datos: las URLs
http://hardcodeadas en contenido de curso viven en la BD. Existen herramientas de búsqueda/reemplazo masivo pensadas para esto (siempre con copia de seguridad previa de la base de datos, porque un reemplazo mal acotado puede tocar campos que no debía). - Corrección: sustituye las referencias por
https://o por URLs relativas al protocolo (//dominio/recurso, que hereda el protocolo de la página). Revisa además los plugins que puedan estar generando estos enlaces. - Reverificación: vuelve a pasar la consola y el escáner. El candado debe quedar limpio, sin el aviso de “conexión no totalmente segura”, en todas las páginas que antes fallaban.
Certificados caducados: el fallo silencioso más costoso
Un certificado SSL caducado convierte instantáneamente tu Moodle en un sitio que el navegador marca como no seguro, bloqueando en muchos casos el acceso directo sin que el usuario sepa cómo continuar. Si usas Let’s Encrypt, confirma que la renovación automática está realmente funcionando (no solo configurada) probándola periódicamente, ya que un fallo silencioso en el proceso de renovación puede pasar desapercibido hasta el mismo día de la caducidad.
Checklist de configuración SSL/HTTPS
| Punto | Verificado |
|---|---|
| Certificado SSL instalado sin errores de cadena de confianza | ☐ |
| Renovación automática configurada y probada (si usas Let’s Encrypt) | ☐ |
$CFG->wwwroot con https:// en config.php | ☐ |
$CFG->sslproxy = true; si hay proxy/balanceador que termina el TLS | ☐ |
| HTTPS forzado en todo el sitio, no solo en el login | ☐ |
| Redirección 301 de HTTP a HTTPS a nivel de servidor | ☐ |
$CFG->cookiesecure = true; (cookies de sesión solo por HTTPS) | ☐ |
| Sin avisos de contenido mixto en las páginas principales del sitio | ☐ |
| Fecha de caducidad del certificado monitorizada con antelación | ☐ |
Preguntas frecuentes
¿Un certificado SSL gratuito (Let’s Encrypt) es suficiente para Moodle? Sí, en términos de cifrado es igual de válido que uno de pago; la diferencia está en la renovación automática, que hay que configurar y verificar periódicamente en el caso de Let’s Encrypt.
¿Qué es el contenido mixto y por qué genera avisos en el navegador? Es cuando una página servida por HTTPS carga recursos (imágenes, scripts) todavía por HTTP sin cifrar, lo que los navegadores modernos bloquean o marcan como inseguro.
¿Cómo sé si mi Moodle tiene problemas de contenido mixto? Revisando la consola de desarrollador del navegador en distintas páginas del sitio, donde aparecen advertencias específicas sobre recursos cargados de forma no segura.
¿Basta con cambiar $CFG->wwwroot a HTTPS para que todo funcione bien?
Es un paso necesario pero no suficiente: también hay que forzar HTTPS en la configuración de seguridad del sitio y corregir cualquier contenido con referencias absolutas a HTTP.
¿Qué pasa si mi certificado SSL caduca sin que lo note? El sitio queda marcado como no seguro por el navegador, bloqueando en muchos casos el acceso directo de los usuarios hasta que se renueve el certificado.
¿Necesito una redirección a nivel de servidor además de la configuración de Moodle? Sí, para asegurar que ninguna petición llega a completarse por HTTP sin cifrar, la redirección 301 a nivel de servidor web es la capa que cierra ese hueco.
¿Los vídeos o iframes embebidos de otros servicios pueden causar contenido mixto?
Sí, si se referencian con http:// en vez de https://, incluso si el resto del sitio está correctamente configurado en HTTPS.
Mi Moodle entra en un bucle de redirección (ERR_TOO_MANY_REDIRECTS), ¿por qué?
El caso clásico es tener Moodle detrás de un proxy, balanceador o CDN que termina el TLS: el usuario navega por HTTPS, pero Moodle recibe la petición por HTTP interno y no para de redirigir. Se arregla añadiendo $CFG->sslproxy = true; en config.php. Si no hay ninguna capa por delante, el bucle suele venir de una redirección de servidor mal escrita, no de sslproxy.
¿Debo activar $CFG->cookiesecure?
Sí, siempre que wwwroot sea HTTPS. Hace que la cookie de sesión solo viaje por conexiones cifradas, cerrando el robo de sesión por interceptación. Dejarlo desactivado con el sitio en HTTPS es un descuido de seguridad innecesario.
¿Merece la pena activar HSTS en Moodle?
Sí, pero solo cuando estés seguro de que todo el sitio y sus subdominios sirven correctamente por HTTPS. HSTS obliga al navegador a usar HTTPS siempre para tu dominio; si después un subdominio se queda sin certificado válido, quedará inaccesible hasta que la política caduque en el navegador. Empieza con un max-age corto y súbelo cuando lo hayas verificado.
¿Cada cuánto hay que renovar un certificado de Let’s Encrypt?
Cada 90 días, pero la gracia es que no lo hagas a mano: la renovación automática (Certbot o el emisor del panel) lo renueva antes de caducar. Basta con verificar de vez en cuando que el proceso funciona de verdad, con un certbot renew --dry-run o comprobando que el panel lo está reinstalando.
Conclusión
Configurar SSL en Moodle no termina con instalar el certificado, implica forzar HTTPS de forma consistente en todo el sitio, corregir cualquier contenido mixto heredado, y vigilar activamente que la renovación del certificado realmente funciona, no solo que está configurada. Cada uno de estos puntos por separado es sencillo; lo que falla, casi siempre, es no revisarlos como conjunto.
Si prefieres que alguien verifique y mantenga esto por ti, en Avantys lo incluimos como parte del mantenimiento continuo de cada Moodle que gestionamos. Puedes pedir una auditoría gratuita en Moodle Gestionado.
Artículos relacionados
- Mantenimiento y hosting Moodle: guía completa
- Checklist de hardening de Moodle
- Cómo proteger Moodle de ataques y vulnerabilidades
¿Y si tu Moodle lo lleváramos nosotros?
Actualizaciones, backups verificados, rendimiento y trazabilidad FUNDAE, gestionado de forma continua por una persona que responde. Auditoría gratuita de tu plataforma actual.
