Cómo emitir certificados verificables desde Moodle (y por qué el plugin no alcanza)

Moodle sabe perfectamente quién aprobó cada curso. Lo que no sabe hacer es responderle a un empleador cinco años después, cuando ese curso ya no existe y la persona hace tiempo que no es alumna. Esa brecha, y no el diseño del certificado, es la que define si lo que la institución emite vale algo fuera del campus.

Respuesta directa: emitir certificados verificables desde Moodle no se resuelve con las herramientas nativas. Hay tres formas de entregar un certificado (el plugin Custom Certificate, las insignias nativas y la exportación manual a otra plataforma) y ninguna produce una credencial digital verificable que un tercero pueda comprobar de manera independiente y permanente. El plugin genera un PDF cuya validación vive dentro del mismo Moodle y está desactivada para los de afuera hasta que un administrador la habilita. Las insignias sí son Open Badges, pero la documentación de desarrollo de Moodle indica que la plataforma soporta las versiones 2.0 y 2.1, y que la 3.0 llegará más adelante. La cuarta vía es conectar el LMS con una plataforma de credenciales por LTI 1.3: la emisión se dispara desde la nota del curso y la credencial queda fuera del LMS, con página pública de verificación propia.

Puntos clave

• El PDF del plugin se verifica contra tu propio Moodle. Cada certificado lleva un código único, pero quien lo recibe solo puede comprobarlo si el administrador activó la opción "Permitir que cualquiera verifique un certificado". Sin eso, verificar requiere una cuenta con permisos dentro de la plataforma.
• Las insignias nativas van una generación atrás del estándar. Son Open Badges 2.0 y 2.1. La versión 3.0, la que se alinea con las Credenciales Verificables del W3C, todavía no está.
• El LMS y la credencial tienen relojes distintos. El curso dura un semestre y la plataforma se migra cada tantos años. La credencial tiene que sobrevivir a una carrera profesional entera.
• La integración LTI 1.3 elimina la planilla. POK lee la nota del libro de calificaciones y emite cuando el alumno supera el mínimo definido, sin exportar ni volver a cargar listas.
• No hace falta instalar nada en el servidor. El registro se hace desde el panel de administración de Moodle, en Herramientas externas, sin acceso por SSH ni despliegue de código.

Las tres formas de certificar que Moodle ya ofrece

Moodle es, por lejos, el LMS más extendido del mundo: sus estadísticas públicas reportan más de 146.000 sitios registrados y unos 529 millones de usuarios. Y el dato que más importa para el mundo hispanohablante es la distribución: España es el país con más sitios registrados, y México y Brasil aparecen entre los seis primeros. Buena parte de la educación superior de la región corre sobre esta plataforma.

Eso significa que casi ninguna institución arranca su programa de credenciales desde cero. Arranca desde algo que ya funciona en Moodle. Conviene entonces mirar con precisión qué prueba cada una de esas tres opciones, porque las diferencias no están donde uno espera.

1. El plugin Custom Certificate

Es la opción por defecto de medio mundo. Custom Certificate genera, según la documentación oficial de Moodle, "certificados PDF dinámicos con personalización completa desde el navegador". Se diseña la plantilla arrastrando elementos, se agrega la actividad al curso y el alumno descarga su PDF.

Trae verificación, y esto suele sorprender: cada certificado emitido recibe un código único que se puede imprimir en el documento, y existe una página donde alguien ingresa ese código para comprobar su autenticidad. Hasta ahí, suena resuelto.

El detalle está en quién puede usar esa página. La documentación es explícita: para verificar hace falta la capacidad mod/customcert:verifycertificate, es decir, un usuario con permisos dentro de tu Moodle. Solo si el administrador activa la opción "Permitir que cualquiera verifique un certificado" puede hacerlo alguien sin sesión iniciada. O sea que el comportamiento por defecto del plugin de certificados más instalado del ecosistema es que un empleador externo no pueda verificar nada.

Y aun con la opción activada, quedan dos cosas en pie. La primera es que la página de verificación vive en el dominio de tu Moodle, así que la prueba depende de que esa URL siga respondiendo. La segunda es que el artefacto que circula es un PDF, y un PDF se edita.

El costo de todo esto no es teórico y lo paga siempre la misma área. Mientras la verificación no sea pública, comprobar un certificado vuelve a ser una persona de registros académicos contestando correos de a uno, que es exactamente el trabajo que un certificado digital tenía que eliminar.

2. Las insignias nativas de Moodle

Es la opción mejor pensada de las tres y la que menos se usa. Las insignias de Moodle son Open Badges de verdad: metadatos incrustados en la imagen, criterios de obtención, emisor identificado, y se pueden enviar a una mochila digital.

El límite es de versión. La documentación para desarrolladores de Moodle lo dice sin vueltas: la plataforma soporta hoy Open Badges 2.0 y 2.1, que comparten esquema, y agregará Open Badges 3.0 más adelante porque el esquema es distinto. Esa diferencia de numeración parece menor y no lo es. Open Badges 3.0 es la versión que se alineó con el modelo de Credenciales Verificables del W3C, el que permite que la credencial se compruebe criptográficamente sin depender de que el servidor del emisor conteste en ese momento. Es exactamente el problema que uno quiere resolver.

Mientras tanto, la insignia nativa se hospeda en tu Moodle y su verificación apunta ahí.

3. Exportar la lista y cargarla en otro lado

La tercera vía no es una función de Moodle, es lo que termina haciendo el equipo académico: descargar el libro de calificaciones, filtrar quiénes aprobaron, limpiar la planilla, subirla a una plataforma de credenciales y corregir los correos mal tipeados.

Funciona, y es la que más horas consume y más errores acumula. Cada cohorte se paga completa de nuevo. Y a medida que el programa crece, el cuello de botella deja de ser la emisión y pasa a ser la persona que arma la planilla.

	Custom Certificate (PDF)	Insignias nativas	Exportar y cargar a mano	Integración LTI con plataforma externa
Qué recibe el alumno	Un archivo PDF	Una imagen con metadatos	Depende de la plataforma	Credencial en una billetera digital
Quién puede verificar	Solo usuarios con permisos, salvo que se habilite el acceso público	Cualquiera, contra tu Moodle	Depende de la plataforma	Cualquiera, desde una página pública
Dónde vive la prueba	En tu servidor de Moodle	En tu servidor de Moodle	Fuera del LMS	Fuera del LMS, en el registro del emisor
Estándar	Ninguno	Open Badges 2.0 y 2.1	Depende de la plataforma	Open Badges 3.0
Si se borra el curso o migra el sitio	Se cae la verificación	Se cae la verificación	No afecta	No afecta
Trabajo por cohorte	Configuración inicial	Configuración inicial	Horas de planilla	Ninguno
Se puede revocar	No	Sí, dentro de Moodle	Depende de la plataforma	Sí, con constancia pública

El problema de fondo: el LMS y la credencial no envejecen igual

Todo lo anterior tiene una sola causa, y no es un defecto de Moodle. Moodle hace bien lo que fue diseñado para hacer: correr un curso, evaluar y llevar el registro académico mientras la persona es alumna.

El punto es que la vida útil de un curso y la vida útil de una credencial no se parecen en nada. El curso dura un semestre. La plataforma se actualiza cada año y se migra cada tantos. Las categorías se reorganizan, los cursos viejos se archivan o se borran para liberar espacio, el alumno se desmatricula al egresar. La credencial, en cambio, tiene que seguir en pie cuando esa persona la muestre en una entrevista dentro de siete años.

Cuando la prueba de un título vive dentro del sistema que corre los cursos, hereda la fecha de vencimiento equivocada. No es que alguien vaya a falsificarla: es que el día que un empleador vaya a comprobarla, la URL puede no existir, el sitio puede haber cambiado de dominio o la verificación puede haber quedado detrás del login en una migración que nadie asoció con los certificados emitidos en 2021.

Es la misma pregunta que se hace cualquier área de registros académicos antes de dar de baja un sistema viejo: quién responde por estos documentos cuando esto ya no esté. Un LMS es un excelente motor de cursos y un mal registro de largo plazo, y no hay configuración que lo cambie.

Qué hace distinto una integración LTI 1.3

LTI 1.3 es el estándar de 1EdTech con el que un LMS se conecta a una herramienta externa sin que las dos plataformas se fusionen. Es el mismo mecanismo con el que Moodle integra un proctoring o una biblioteca de contenidos.

Aplicado a credenciales, cambia tres cosas concretas.

El disparo lo hace la nota, no una persona. En la configuración de la credencial se elige una evaluación del curso y una nota mínima, por ejemplo aprobar con más de 80. POK lee esa calificación del servicio de notas del LMS y emite a quienes califican. Nadie exporta nada. Vale aclarar el borde: si la plataforma no expone la nota por ese servicio, la credencial se entrega igual, sin la condición.

La credencial nace fuera del LMS. El registro queda en el emisor, con su propia página pública de verificación, y esa página no depende de que el curso siga existiendo ni de que el Moodle esté en línea. Se puede además emitir con respaldo en blockchain, lo que agrega una prueba que ni siquiera depende de la plataforma emisora. Y como el registro es del emisor, una credencial mal emitida se puede revocar dejando constancia pública, algo que un PDF ya descargado no permite.

No se instala nada en el servidor. Este punto define si el proyecto arranca este mes o el próximo trimestre. El registro se hace desde el panel de administración de Moodle, en Herramientas externas, pegando una URL que entrega POK. No hay que subir un plugin, ni pedirle acceso por SSH al proveedor de hosting, ni esperar una ventana de mantenimiento. Para Moodle 3.10 en adelante alcanza con pegar la URL y confirmar; en versiones anteriores la conexión se configura a mano con los mismos datos.

Cómo queda armado en el curso

Una vez registrada la integración, la credencial se agrega al curso como una actividad de tipo Herramienta externa, eligiendo la herramienta POK ya preconfigurada. Al abrirla se define el diseño de la credencial, si tiene fecha de expiración, cómo se mapean los datos del alumno y si se emite como credencial básica o en blockchain.

Del lado del alumno el recorrido es corto: abre la actividad dentro del curso, completa los datos de perfil que falten y recibe dos correos, uno para aceptar la credencial y otro con la credencial ya emitida.

Del lado de la coordinación queda una lista con el estado de cada estudiante: pendiente, enviada o aceptada. Desde ahí se puede reenviar a los pendientes sin que los que ya la tienen reciban nada dos veces, que es el error clásico de la emisión por planilla.

Qué pasa cuando el alumno deja la institución

Este es el punto que casi nunca entra en la evaluación técnica y es el que más define el valor del programa.

Con certificados alojados en el LMS, el egresado pierde el acceso cuando se le da de baja la cuenta. El PDF que descargó sigue en alguna carpeta, pero ya no hay nada que lo respalde. Con una credencial emitida fuera del LMS, la persona la conserva en su billetera de credenciales digitales, la comparte en LinkedIn con un enlace que resuelve a la página de verificación del emisor, y sigue siendo verificable sin que la institución tenga que hacer nada.

Queda un caso que ese recorrido no cubre, y conviene preverlo: el empleador que no recibió el enlace y solo tiene el nombre del egresado. Para eso la institución puede publicar una consulta pública de credenciales, un buscador de lo que emitió al que se llega por los datos del titular en lugar del enlace.

Ahí está el retorno real de conectar el LMS: no es ahorrar el trabajo de la planilla, aunque lo ahorre. Es que cada egresado se convierte en un canal de difusión permanente de la institución, con una prueba que se puede comprobar en un clic. Es la diferencia entre entregar un archivo y dejar un registro.

Por dónde empezar

1. Revisar la versión de Moodle. De 3.10 en adelante el registro es automático. Se consulta en Administración del sitio, Notificaciones, al pie de la página.
2. Elegir un curso piloto, no el catálogo entero. Uno con evaluación clara y una cohorte que termine pronto, para ver el circuito completo antes de escalarlo. Si el programa apila reconocimientos, conviene decidir de entrada qué microcredencial reconoce cada curso.
3. Definir la regla de emisión antes que el diseño. Qué evaluación cuenta y cuál es la nota mínima. Es la decisión académica del asunto; el resto es configuración.
4. Conectar y probar con una cohorte real. La guía de integración de Moodle con POK tiene el paso a paso para las dos variantes de versión.

El mismo camino sirve para Canvas, Blackboard, D2L Brightspace y Open edX, que también se conectan por LTI 1.3 desde el panel de integraciones. Una institución con más de un LMS conviviendo, que es lo habitual cuando el posgrado y el pregrado eligieron distinto, emite con las mismas credenciales desde todos.

POK es emisor certificado de Open Badges 3.0 por 1EdTech, cuenta con certificación ISO 27001 y SOC 2, y trabaja con más de 1.100 instituciones en más de 19 países. La integración funciona igual en el plan gratuito que en los planes con respaldo en blockchain: lo que cambia es dónde queda el registro, no cómo llega el dato desde el curso.

Preguntas frecuentes

¿Se pueden emitir certificados verificables desde Moodle?

Sí, pero no con las herramientas nativas de Moodle por sí solas. El plugin Custom Certificate de Moodle genera un PDF con un código de verificación que se comprueba contra el propio sitio Moodle de la institución, y solo por usuarios con permisos salvo que el administrador habilite el acceso público. Las insignias nativas de Moodle son Open Badges 2.0 y 2.1, hospedadas también en ese mismo Moodle. Para que la credencial sea verificable de manera independiente y permanente, Moodle tiene que conectarse por LTI 1.3 con una plataforma de credenciales como POK Proof of Knowledge, de modo que la credencial se emita y se verifique fuera del LMS.

¿Qué diferencia hay entre el plugin Custom Certificate de Moodle y una credencial digital verificable?

El plugin Custom Certificate de Moodle produce un archivo PDF y hospeda su verificación dentro del propio Moodle. Una credencial digital verificable se emite en un registro externo al LMS, con su propia página pública, sigue un estándar abierto como Open Badges 3.0 y puede tener respaldo criptográfico en blockchain. La diferencia práctica aparece con el tiempo: el PDF depende de que la URL del Moodle siga viva y de que la opción de verificación pública siga activada, mientras que una credencial emitida con una plataforma como POK sobrevive a la migración del LMS, al borrado del curso y a la baja de la cuenta del egresado.

¿Las insignias de Moodle son Open Badges 3.0?

No. La documentación para desarrolladores de Moodle indica que Moodle soporta Open Badges 2.0 y 2.1, que comparten esquema, y que sumará Open Badges 3.0 más adelante porque usa un esquema distinto. La 3.0 es la versión alineada con el modelo de Credenciales Verificables del W3C, que es la que permite comprobar una credencial sin depender de que el servidor del emisor responda en ese momento. Esa limitación es de las insignias nativas de Moodle, no de las credenciales emitidas por fuera: POK es emisor de Open Badges 3.0 certificado por 1EdTech.

¿Hay que instalar un plugin en el servidor para conectar Moodle con POK?

No para la integración por LTI. El registro se hace desde el panel de administración de Moodle, en Administración del sitio, Plugins, Herramienta externa, Gestionar herramientas, pegando la URL que entrega POK. No requiere acceso por SSH, ni despliegue de código, ni ventana de mantenimiento. POK ofrece además una integración por API mediante un plugin propio, para instituciones que prefieren ese camino.

¿Se puede emitir la credencial solo a quienes aprueban con determinada nota?

Sí. En la configuración de la credencial se elige una evaluación del curso y se define la nota mínima, y POK lee esa calificación del servicio de notas del LMS para emitir únicamente a quienes la alcanzan. Si la plataforma no expone la nota por ese servicio, la credencial se entrega de todas formas, sin la condición. También se puede prescindir de la regla y dejar que el alumno genere la credencial al terminar el curso.

¿Qué versión de Moodle hace falta?

La conexión funciona en las versiones vigentes. Desde Moodle 3.10 el registro es dinámico: POK entrega una URL, se pega en Gestionar herramientas y se confirma con "Agregar LTI Advantage". En Moodle 3.9 o anteriores la herramienta se configura a mano, cargando el ID de plataforma, el ID de cliente y un token de servicio web. La versión instalada se consulta al pie de Administración del sitio, Notificaciones.

¿Qué pasa con las credenciales si la institución migra o apaga su Moodle?

Nada, si se emitieron fuera del LMS. Ese es justamente el motivo para separar la emisión de la plataforma de cursos: el registro y la página pública de verificación viven en el emisor, así que una migración de Moodle, el archivado de un curso viejo o la baja de la cuenta del egresado no afectan la credencial. Si en cambio la verificación estaba hospedada en Moodle, deja de responder y los certificados emitidos quedan sin respaldo comprobable.

¿Sirve la misma integración para Canvas o Blackboard?

Sí. POK se conecta por LTI 1.3 con Moodle, Canvas, Blackboard, D2L Brightspace y Open edX, y con Sana por xAPI. Canvas admite además la conexión por API Key. Para un campus propio o un desarrollo a medida hay una integración personalizada por URL LTI o API Key, y una API REST con webhooks. Una institución que convive con más de un LMS emite las mismas credenciales desde todos ellos.

Lecturas relacionadas

• Cómo verifican los empleadores las credenciales digitales en 2026
• Open Badge 3.0: la guía completa de credenciales digitales
• Cómo implementar microcredenciales en una universidad, paso a paso
• El verdadero valor de las credenciales digitales: de commodity a infraestructura de confianza

Para ver cómo POK se conecta con el LMS que ya usa la institución, se pueden revisar los planes y precios o agendar una demo.

Última actualización: 14 de septiembre de 2026.