Como emitir certificados verificáveis pelo Moodle (e por que o plugin não basta)

O Moodle sabe exatamente quem foi aprovado em cada curso. O que ele não consegue fazer é responder a um empregador cinco anos depois, quando aquele curso já não existe e a pessoa há tempos deixou de ser aluna. É essa lacuna, e não o design do certificado, que define se o que a instituição emite vale alguma coisa fora do campus.

Resposta direta: emitir certificados verificáveis pelo Moodle não se resolve com as ferramentas nativas. São três as formas de entregar um certificado (o plugin Custom Certificate, os emblemas nativos e a exportação manual para outra plataforma) e nenhuma delas produz uma credencial digital verificável que um terceiro possa conferir de forma independente e permanente. O plugin gera um PDF cuja validação vive dentro do próprio Moodle e fica desativada para quem está de fora até que um administrador a habilite. Os emblemas nativos são Open Badges de verdade, mas a documentação de desenvolvimento do Moodle informa que a plataforma suporta as versões 2.0 e 2.1, e que a 3.0 virá mais adiante. O quarto caminho é conectar o LMS a uma plataforma de credenciais por LTI 1.3: a emissão é disparada pela nota do curso e a credencial fica fora do LMS, com página pública de verificação própria.

Pontos principais

• O PDF do plugin é verificado contra o seu próprio Moodle. Cada certificado leva um código único, mas quem o recebe só consegue conferir se o administrador ativou a opção "Permitir que qualquer pessoa verifique um certificado". Sem isso, verificar exige uma conta com permissões dentro da plataforma.
• Os emblemas nativos estão uma geração atrás do padrão. São Open Badges 2.0 e 2.1. A versão 3.0, alinhada às Credenciais Verificáveis do W3C, ainda não chegou.
• O LMS e a credencial correm em relógios diferentes. O curso dura um semestre e a plataforma é migrada a cada poucos anos. A credencial precisa sobreviver a uma carreira inteira.
• A integração LTI 1.3 elimina a planilha. A POK lê a nota do diário de classe e emite quando o aluno supera o mínimo definido, sem exportar nem recarregar listas.
• Não é preciso instalar nada no servidor. O registro é feito pelo painel de administração do Moodle, em Ferramentas externas, sem acesso por SSH nem implantação de código.

As três formas de certificar que o Moodle já oferece

O Moodle é, de longe, o LMS mais difundido do mundo: suas estatísticas públicas registram mais de 146 mil sites e cerca de 529 milhões de usuários. E o dado que mais importa por aqui é a distribuição: o Brasil aparece entre os seis países com mais instalações, ao lado de Espanha, Estados Unidos, Alemanha, México e França. Boa parte do ensino superior da região roda nessa plataforma.

Isso significa que quase nenhuma instituição começa seu programa de credenciais do zero. Começa a partir de algo que já funciona no Moodle. Vale então olhar com precisão o que cada uma dessas três opções realmente comprova, porque as diferenças não estão onde se imagina.

1. O plugin Custom Certificate

É a escolha padrão de quase todo mundo. Segundo a documentação oficial do Moodle, o Custom Certificate permite gerar certificados em PDF dinâmicos com personalização completa pelo navegador. O modelo é desenhado arrastando elementos, a atividade é adicionada ao curso e o aluno baixa o PDF.

Ele traz verificação, e isso costuma surpreender: cada certificado emitido recebe um código único que pode ser impresso no documento, e existe uma página onde alguém digita esse código para confirmar a autenticidade. Até aí, parece resolvido.

O detalhe está em quem pode usar essa página. A documentação é explícita: verificar exige a capacidade mod/customcert:verifycertificate, ou seja, um usuário com permissões dentro do seu Moodle. Só quando o administrador ativa a opção "Permitir que qualquer pessoa verifique um certificado" é que alguém sem sessão iniciada consegue fazê-lo. Em outras palavras, o comportamento padrão do plugin de certificados mais instalado do ecossistema é que um empregador externo não consegue verificar nada.

E mesmo com a opção ativada, duas coisas permanecem. A página de verificação vive no domínio do seu Moodle, então a prova depende de aquela URL continuar respondendo. E o artefato que circula é um PDF, e PDF se edita.

O custo disso tudo não é teórico, e quem paga é sempre o mesmo setor. Enquanto a verificação não for pública, conferir um certificado volta a ser uma pessoa da secretaria acadêmica respondendo e-mails um a um, que é exatamente o trabalho que um certificado digital deveria eliminar.

2. Os emblemas nativos do Moodle

É a opção mais bem pensada das três e a menos usada. Os emblemas do Moodle são Open Badges de verdade: metadados embutidos na imagem, critérios de obtenção, emissor identificado e a possibilidade de enviá-los para uma mochila digital.

O limite é de versão. A documentação para desenvolvedores do Moodle diz sem rodeios: a plataforma suporta hoje Open Badges 2.0 e 2.1, que compartilham o mesmo esquema, e acrescentará Open Badges 3.0 mais adiante porque o esquema é outro. Essa diferença de numeração parece cosmética e não é. O Open Badges 3.0 é a versão alinhada ao modelo de Credenciais Verificáveis do W3C, aquela que permite comprovar a credencial criptograficamente sem depender de o servidor do emissor responder naquele momento. Que é exatamente o problema que vale a pena resolver.

Enquanto isso, o emblema nativo fica hospedado no seu Moodle e sua verificação aponta para lá.

3. Exportar a lista e carregar em outro lugar

O terceiro caminho não é um recurso do Moodle, é o que a equipe acadêmica acaba fazendo: baixar o diário de classe, filtrar quem foi aprovado, limpar a planilha, subir para uma plataforma de credenciais e corrigir os e-mails digitados errado.

Funciona, e é o que mais consome horas e mais acumula erros. Cada turma paga o custo inteiro de novo. Conforme o programa cresce, o gargalo deixa de ser a emissão e passa a ser a pessoa que monta a planilha.

	Custom Certificate (PDF)	Emblemas nativos	Exportar e carregar à mão	Integração LTI com plataforma externa
O que o aluno recebe	Um arquivo PDF	Uma imagem com metadados	Depende da plataforma	Credencial em uma carteira digital
Quem pode verificar	Só usuários com permissões, salvo se o acesso público for habilitado	Qualquer pessoa, contra o seu Moodle	Depende da plataforma	Qualquer pessoa, por uma página pública
Onde vive a prova	No seu servidor Moodle	No seu servidor Moodle	Fora do LMS	Fora do LMS, no registro do emissor
Padrão	Nenhum	Open Badges 2.0 e 2.1	Depende da plataforma	Open Badges 3.0
Se o curso é apagado ou o site migra	A verificação cai	A verificação cai	Não afeta	Não afeta
Trabalho por turma	Configuração inicial	Configuração inicial	Horas de planilha	Nenhum
Dá para revogar	Não	Sim, dentro do Moodle	Depende da plataforma	Sim, com registro público

O problema de fundo: o LMS e a credencial não envelhecem igual

Tudo o que está acima tem uma causa só, e não é um defeito do Moodle. O Moodle faz bem aquilo para o que foi desenhado: rodar um curso, avaliar e manter o registro acadêmico enquanto a pessoa é aluna.

A questão é que a vida útil de um curso e a vida útil de uma credencial não se parecem em nada. O curso dura um semestre. A plataforma é atualizada todo ano e migrada a cada poucos. As categorias são reorganizadas, cursos antigos são arquivados ou apagados para liberar espaço, o aluno é desmatriculado ao se formar. Já a credencial precisa continuar de pé quando essa pessoa a mostrar em uma entrevista daqui a sete anos.

Quando a prova de uma conquista vive dentro do sistema que roda os cursos, ela herda a data de validade errada. Não é que alguém vá falsificá-la: é que no dia em que um empregador for conferir, a URL pode não existir, o site pode ter mudado de domínio ou a verificação pode ter ficado atrás do login depois de uma migração que ninguém associou aos certificados emitidos em 2021.

É a mesma pergunta que qualquer secretaria acadêmica faz antes de desativar um sistema antigo: quem responde por estes documentos quando isto aqui não existir mais. Um LMS é um excelente motor de cursos e um mau registro de longo prazo, e não há configuração que mude isso.

O que muda com uma integração LTI 1.3

LTI 1.3 é o padrão da 1EdTech com o qual um LMS se conecta a uma ferramenta externa sem que as duas plataformas se fundam. É o mesmo mecanismo com que o Moodle integra um proctoring ou uma biblioteca de conteúdos.

Aplicado a credenciais, ele muda três coisas concretas.

Quem dispara é a nota, não uma pessoa. Na configuração da credencial se escolhe uma avaliação do curso e uma nota mínima, por exemplo aprovar acima de 80. A POK lê essa nota do serviço de notas do LMS e emite para quem se qualifica. Ninguém exporta nada. Vale deixar claro o limite: se a plataforma não expõe a nota por esse serviço, a credencial é entregue do mesmo jeito, sem a condição.

A credencial nasce fora do LMS. O registro fica com o emissor, com página pública de verificação própria, e essa página não depende de o curso continuar existindo nem de o Moodle estar no ar. Ela também pode ser emitida com respaldo em blockchain, o que acrescenta uma prova que nem sequer depende da plataforma emissora. E como o registro é do emissor, uma credencial emitida por engano pode ser revogada com constância pública, o que um PDF já baixado não permite.

Nada é instalado no servidor. Esse ponto define se o projeto começa neste mês ou no próximo trimestre. O registro é feito pelo painel de administração do Moodle, em Ferramentas externas, colando uma URL que a POK fornece. Não há plugin para subir, nem pedido de acesso SSH ao provedor de hospedagem, nem janela de manutenção. Do Moodle 3.10 em diante basta colar a URL e confirmar; em versões anteriores a conexão é configurada à mão com os mesmos dados.

Como fica montado no curso

Uma vez registrada a integração, a credencial é adicionada ao curso como uma atividade do tipo Ferramenta externa, escolhendo a ferramenta POK já preconfigurada. Ao abri-la se define o design da credencial, se ela tem data de expiração, como os dados do aluno são mapeados e se a emissão é básica ou em blockchain.

Do lado do aluno o percurso é curto: abre a atividade dentro do curso, completa os dados de perfil que faltam e recebe dois e-mails, um para aceitar a credencial e outro com a credencial já emitida.

Do lado da coordenação fica uma lista com o status de cada estudante: pendente, enviada ou aceita. De lá dá para reenviar aos pendentes sem que quem já recebeu receba duas vezes, que é o erro clássico da emissão por planilha.

O que acontece quando o aluno deixa a instituição

Este é o ponto que quase nunca entra na avaliação técnica e é o que mais define o valor do programa.

Com certificados hospedados no LMS, o egresso perde o acesso quando a conta é desativada. O PDF que ele baixou continua em alguma pasta, mas já não há nada que o respalde. Com uma credencial emitida fora do LMS, a pessoa a mantém na sua carteira de credenciais digitais, compartilha no LinkedIn com um link que resolve para a página de verificação do emissor, e ela segue verificável sem que a instituição precise fazer nada.

Há um caso que esse percurso não cobre, e vale prever: o empregador que não recebeu o link e só tem o nome do egresso. Para isso a instituição pode publicar uma consulta pública de credenciais, um buscador do que ela emitiu ao qual se chega pelos dados do titular em vez do link.

É aí que aparece o retorno real de conectar o LMS. Não é economizar o trabalho da planilha, ainda que economize. É que cada egresso se torna um canal permanente de divulgação da instituição, carregando uma prova que qualquer um confere em um clique. É a diferença entre entregar um arquivo e deixar um registro.

Por onde começar

1. Conferir a versão do Moodle. De 3.10 em diante o registro é automático. A informação está no rodapé de Administração do site, Notificações.
2. Escolher um curso piloto, não o catálogo inteiro. Um com avaliação clara e uma turma prestes a terminar, para ver o circuito completo antes de escalar. Se o programa empilha reconhecimentos, convém decidir de saída qual microcredencial cada curso reconhece.
3. Definir a regra de emissão antes do design. Qual avaliação conta e qual é a nota mínima. É a decisão acadêmica do assunto; o resto é configuração.
4. Conectar e testar com uma turma real. O guia de integração do Moodle com a POK traz o passo a passo para as duas variantes de versão.

O mesmo caminho vale para Canvas, Blackboard, D2L Brightspace e Open edX, que também se conectam por LTI 1.3 pelo painel de integrações. Uma instituição com mais de um LMS convivendo, o que é comum quando a pós-graduação e a graduação escolheram diferente, emite as mesmas credenciais a partir de todos eles.

A POK é emissora certificada de Open Badges 3.0 pela 1EdTech, tem certificação ISO 27001 e SOC 2, e trabalha com mais de 1.100 instituições em mais de 19 países. A integração funciona igual no plano gratuito e nos planos com respaldo em blockchain: o que muda é onde fica o registro, não como o dado chega desde o curso.

Perguntas frequentes

Dá para emitir certificados verificáveis pelo Moodle?

Sim, mas não apenas com as ferramentas nativas do Moodle. O plugin Custom Certificate do Moodle gera um PDF com um código de verificação conferido contra o próprio site Moodle da instituição, e só por usuários com permissões, a menos que o administrador habilite o acesso público. Os emblemas nativos do Moodle são Open Badges 2.0 e 2.1, hospedados nesse mesmo Moodle. Para que a credencial seja verificável de forma independente e permanente, o Moodle precisa se conectar por LTI 1.3 a uma plataforma de credenciais como a POK Proof of Knowledge, de modo que a credencial seja emitida e verificada fora do LMS.

Qual é a diferença entre o plugin Custom Certificate do Moodle e uma credencial digital verificável?

O plugin Custom Certificate do Moodle produz um arquivo PDF e hospeda a verificação dentro do próprio Moodle. Uma credencial digital verificável é emitida em um registro fora do LMS, com página pública própria, segue um padrão aberto como o Open Badges 3.0 e pode ter respaldo criptográfico em blockchain. A diferença prática aparece com o tempo: o PDF depende de a URL do Moodle continuar viva e de a opção de verificação pública seguir ativada, enquanto uma credencial emitida por uma plataforma como a POK sobrevive à migração do LMS, ao curso apagado e à conta de egresso desativada.

Os emblemas do Moodle são Open Badges 3.0?

Não. A documentação para desenvolvedores do Moodle informa que o Moodle suporta Open Badges 2.0 e 2.1, que compartilham o mesmo esquema, e que acrescentará o Open Badges 3.0 mais adiante porque ele usa outro esquema. A versão 3.0 é a alinhada ao modelo de Credenciais Verificáveis do W3C, que é o que permite comprovar uma credencial sem depender de o servidor do emissor responder naquele momento. Essa limitação é dos emblemas nativos do Moodle, não das credenciais emitidas por fora: a POK é emissora de Open Badges 3.0 certificada pela 1EdTech.

É preciso instalar um plugin no servidor para conectar o Moodle à POK?

Não para a integração por LTI. O registro é feito pelo painel de administração do Moodle, em Administração do site, Plugins, Ferramenta externa, Gerenciar ferramentas, colando a URL que a POK fornece. Não exige acesso por SSH, nem implantação de código, nem janela de manutenção. A POK oferece ainda uma integração por API através de um plugin próprio, para instituições que preferem esse caminho.

Dá para emitir a credencial só para quem for aprovado com determinada nota?

Sim. Na configuração da credencial se escolhe uma avaliação do curso e se define a nota mínima, e a POK lê essa nota do serviço de notas do LMS para emitir apenas a quem a alcança. Se a plataforma não expõe a nota por esse serviço, a credencial é entregue do mesmo jeito, sem a condição. Também dá para dispensar a regra e deixar que o aluno gere a credencial ao terminar o curso.

Qual versão do Moodle é necessária?

A conexão funciona nas versões vigentes. A partir do Moodle 3.10 o registro é dinâmico: a POK fornece uma URL, ela é colada em Gerenciar ferramentas e confirmada com "Adicionar LTI Advantage". No Moodle 3.9 ou anterior a ferramenta é configurada à mão, informando o ID de plataforma, o ID de cliente e um token de serviço web. A versão instalada aparece no rodapé de Administração do site, Notificações.

O que acontece com as credenciais se a instituição migrar ou desligar o Moodle?

Nada, se elas foram emitidas fora do LMS. É justamente por isso que vale separar a emissão da plataforma de cursos: o registro e a página pública de verificação vivem no emissor, então uma migração do Moodle, o arquivamento de um curso antigo ou a desativação da conta do egresso não afetam a credencial. Se, ao contrário, a verificação estava hospedada no Moodle, ela deixa de responder e os certificados já emitidos ficam sem respaldo conferível.

A mesma integração serve para Canvas ou Blackboard?

Sim. A POK se conecta por LTI 1.3 com Moodle, Canvas, Blackboard, D2L Brightspace e Open edX, e com a Sana por xAPI. O Canvas admite ainda a conexão por API Key. Para um campus próprio ou um desenvolvimento sob medida existe uma integração personalizada por URL LTI ou API Key, além de uma API REST com webhooks. Uma instituição que convive com mais de um LMS emite as mesmas credenciais a partir de todos eles.

Leituras relacionadas

• Como os empregadores verificam credenciais digitais em 2026
• Open Badge 3.0: o guia completo das credenciais digitais
• Como implementar microcredenciais em uma universidade, passo a passo
• O verdadeiro valor das credenciais digitais: de commodity a infraestrutura de confiança

Para ver como a POK se conecta ao LMS que a instituição já usa, é possível consultar os planos e preços ou agendar uma demo.

Última atualização: 14 de setembro de 2026.