How Open edX certificates get issued and what to set up first
Course certificates are enabled in the Open edX LMS through a feature flag, and program certificates are issued by the separate Credentials service. A team that must award completion certificates from a self-hosted Open edX needs to settle both before the first credentialed course opens. Certificate issuance is a platform configuration project, and it is separate from course authoring in Studio, which defines course structure and content but does not switch on award logic. Most teams implement this module before the first paid or credentialed course launches. Learners who finish before the setup is complete can need certificates issued after the fact, which means manual work and a steady stream of support requests.
Course certificates in the LMS can use customized templates per organization or language, can display hours of effort, and can be generated automatically or manually. Decide these choices early. Which organizations and languages need their own template? Should effort hours appear on the certificate? Should awards happen automatically on passing, or should staff trigger them? Each answer determines who approves the certificate wording, whether legal or brand review is needed, and how support handles reissue requests. Confirm the exact setting names and the location of template files in the documentation for the release you deploy, because these details change between named releases.
Program certificates work differently. The Credentials service issues them when a learner completes a defined set of courses, and it depends on catalog data from the Discovery service to know which courses belong to each program. The program design, the catalog configuration and the Credentials setup therefore depend on one another. Before you build templates, define the program structure, the course identifiers and the service accounts that connect the systems. Ask the Credentials and Discovery documentation which versions work together with your deployment, and confirm that the template and signing features you need are available in the version you plan to run.
Start with a short, written list of decisions and checks. Define the issuing rules for each course and each program. Get the certificate text approved by the business owner and, where relevant, counsel. Create a test course and test learner accounts, then run a complete award in a staging environment from enrollment through certificate delivery. Document how a certificate is verified, reissued and revoked. When you request a quote, ask the implementation partner to list in writing which templates, languages, programs and integrations are in scope and what test evidence will be delivered at the end. Keep this work separate from the catalog and content library work, which have their own setup steps.
What the certificates module does in the platform
Open edX certificates are configured in layers: a feature flag turns the module on, templates vary by organization and language, and each course sets how effort and generation work. Program certificates follow a separate path through the Credentials service. The cards below cover what the platform provides and what your team must confirm.
Enabling certificates by feature flag
Course certificates in the LMS are switched on through a feature flag in the site operator configuration, as described in the Open edX site operator documentation. Confirm which flag your release uses and how your Tutor configuration sets it, since the setting may be managed differently from a hand-edited configuration file. Before launch, agree with your course owners which courses will issue certificates and who approves that setting.
Templates per organization and language
Certificate templates can be customized per organization or language, so a course run under one partner can carry that partner's identity, and a learner can receive a certificate in a language they read. Confirm which organizations and languages you need before design starts, because each combination is a separate template to build, check and maintain. Name who signs off on wording, logos and translations for each one.
Displaying hours of effort
Certificates can display the hours of effort for a course, which matters where learners need a documented time commitment, for example for continuing professional development records. Confirm how the course team measures effort and whether those figures are accurate enough to print on a credential. Agree with the course owner who approves the figure and how it is updated when course content changes.
Automatic or manual generation
Certificates can be generated automatically when a learner meets the passing requirements, or generated manually by staff when a case needs review. Choose the mode per course: automatic generation suits high-volume open courses, while manual generation suits courses where staff check completion or identity first. Test the trigger with a learner account before launch and confirm how certificates are regenerated after a correction.
Program certificates in the Credentials repository
Program certificates are documented in the Credentials repository, separate from the course certificate feature in the LMS. A program certificate depends on course completions and on program definitions that come from the course catalog, so the Discovery service must be in place before programs can be issued. Read the repository documentation for the version you plan to run and confirm how program data reaches Credentials.
Confirming templates and branding
Open edX documentation describes the template options, but your logos, colors, signatory details, legal wording and the accessibility of the printed or PDF output are yours to confirm. Ask your legal, brand and accessibility owners to review a sample certificate for each organization and language. Keep the approved files under version control so that a platform upgrade does not change them unnoticed.
How course certificates and program certificates fit together
The LMS issues certificates for individual courses. The Credentials service issues program certificates, which group several courses under one award. These are two separate paths, so plan them as two separate pieces of configuration, testing and sign-off. Course certificates are switched on with a feature flag in the LMS. Once enabled, they can use templates customized per organization or language, can display hours of effort, and can be generated automatically or manually. Decide early whether an operator will trigger generation by hand for pilot courses or whether automatic issuance is ready for your first release.
Program certificates are documented in the Credentials repository, and they depend on a different set of services than course certificates. Learners see one credential, but behind it a program definition lists the courses that count toward it. Confirm in the Credentials documentation how the service learns that a learner completed each listed course. Then confirm the Credentials release that matches your Open edX version, and how your Tutor setup deploys it alongside the LMS, including its own database, service accounts and access to the LMS. Treat program definitions as content that someone owns and maintains after launch.
The Course Discovery application enters the picture because programs are built from courses in the catalog. Discovery holds the course and program records that the program side relies on, so an error in course data can surface later as a program problem. The catalog itself, including the Catalog micro-frontend, is covered on its sibling page. The legacy catalog is planned for removal in Willow, which is listed for December 2026. If you build programs on the legacy catalog now, schedule time to move them before that release. Confirm the exact Discovery requirements for your version before you design program records.
Before you commit to a design, collect five answers from your Open edX version and Tutor setup. First, the release you will run, since Verawood is the current named release and the only one the project supports. Second, the state of the course certificate feature flag in your LMS settings. Third, which templates each organization and language needs, and who approves their wording. Fourth, whether programs must be live at launch, which determines whether Discovery is needed on day one. Fifth, which Credentials release and deployment method you will use. Write these answers into the written scope so the course track and the program track can be tested separately.
Configuration decisions to settle before the build
This table compares the five decisions that shape the certificates build, the options for each one, and the conditions that favor each option. Read each row before scoping, because the answers determine which templates, grading checks and Credentials service setup the work includes. Settling the program and Discovery questions first prevents rework once templates and catalog records are in progress.
| Decision | Options | When each option fits | Confirm before the build |
|---|---|---|---|
| Generation timing | Automatic issue when learners pass, or manual issue after staff review | Automatic fits courses with objective grading and no review step. Manual fits courses where staff verify results or identity first. | Which grades, checks or approvals must be met before a certificate is issued |
| Template scope | One template for all organizations, or templates per organization and language | One template fits a single brand and language. Per organization and language templates fit multi-brand or multilingual catalogs. | The full list of organizations and languages that will issue certificates |
| Hours of effort on the certificate | Display the effort figure, or leave it off | Display fits courses where course owners maintain a stable effort estimate. Leave it off when the figure cannot be kept accurate. | Whether each course has a maintained effort value and who updates it |
| Program certificates | Available at launch, or added in a later phase | Launch fits when programs are part of the offer from day one. A later phase fits when launch courses stand alone and program rules are still open. | Which programs, completion rules and Credentials service settings must exist at launch |
| Discovery dependency | In scope now, or deferred | In scope now when program records must be defined and listed in the catalog at launch. Deferred when certificates issue only at course level. | Whether the catalog owner needs program data from the Course Discovery application at launch |
What data the certificate needs before the first learner finishes
The certificate data has to be correct before automatic generation is switched on for real learners. Course certificates are produced from values held in the LMS and the course itself, and program certificates add a second layer of mapping on top. Once a certificate has been issued and shared, correcting a wrong course name, language, organization or effort figure means reissuing documents that learners, employers and accreditors may already hold. The five data sets below are the ones to verify first.
The first set is the course identifiers and display names, together with the organization and language that the certificate template selection uses. Templates can be customized per organization or per language, so a course with a mismatched organization value or an unexpected language setting can fall through to the wrong template or to the default. Confirm which organization code each course key carries, which languages you have templates for, and what the platform does when a course has no matching template. Then check that each course name matches the title learners see in the catalog.
The second set is learner names as stored in the LMS. The name printed on a certificate comes from the account profile, not the username or email address, so a learner with an incomplete, misspelled or unusually formatted name will receive a certificate that shows exactly that. Decide in advance whether you rely on self-entered names, whether learners can change them after issue, and what your policy is for name corrections. Test with accounts that include accents, hyphens, apostrophes and non-Latin characters, and confirm the rendered PDF shows them correctly.
The third set is the effort hours for each course, which the certificate can display when that option is enabled. The value is entered per course by the course team, so it is a one-time setup task that recurs whenever a course is revised. Ask each course owner to sign off the figure against the description in your catalog. An error here appears on every certificate issued for that course, so treat it as a content review item rather than a formatting detail.
The fourth set is the course-to-program mapping for program credentials. Program certificates depend on the Credentials service knowing which courses belong to each program and reading program and course data from Discovery, so a missing or duplicated mapping means a learner can complete every course without receiving the program credential, or receive one that lists the wrong courses. Before launch, enroll test accounts in each course, complete them, and check the course certificate fields against your sign-off sheet. Then confirm that each test account moves to the correct program status, including a test learner enrolled in two programs that share a course.
Implementation sequence and the output of each step
The sequence moves from confirming the platform release and deployment, through a non-production trial, to a controlled production launch. Each step closes with a named artifact that the next step depends on, so certificates issued to real learners are the result of checks that were already signed off.
Confirm the release and Tutor deployment baseline
Record the Open edX release, the Tutor version, the installed plugins and the hosting model before any certificate work starts. Your team and the implementation partner confirm which release is running and whether the Credentials service is already deployed or must be added. Open edX supports only the latest named release, so this baseline decides which documentation applies. Output: a signed baseline record listing release, Tutor version, plugins and hosting, with an open list of gaps to close.
Enable the course certificate feature flag in non-production
Turn on the course certificate feature flag in a non-production environment that mirrors production configuration as closely as practical. Verify that the LMS shows the certificate settings for a test course and that the instructor can see certificate status. Confirm the flag and related settings against the Open edX site operator documentation for the release you run, since flag names and locations can change between releases. Output: a non-production environment where certificates are enabled, with the change recorded in version control or the deployment configuration.
Define templates per organization and language
Design the certificate templates for each issuing organization and each language your learners use. Decide which fields appear on each template, such as learner name, course name, organization, signatory and, if you want it, the hours of effort that Open edX can display. Your designers and the platform team agree on layout, legal wording and signatory details with your academic or compliance owner. Output: a signed-off template set with a version number for each organization and language combination, stored with the configuration.
Test automatic and manual generation with test learners
Create test learner accounts and enroll them in test courses that cover the scenarios that matter: passing, failing, a verified track if you use one, and each organization and language template. Run automatic generation first, then trigger manual generation for a learner from the instructor tools. Check the rendered PDFs and the stored certificate records for each combination. Output: a test certificate set with a checklist showing the expected and actual result for every scenario, reviewed by the business owner.
Set up program credentials and Discovery dependencies
Include this step only if program certificates are in scope. Program certificates are documented in the Credentials repository, and they depend on course and program data that flows through the Discovery service, so the catalog must be in place first. Confirm with the catalog work stream which courses and programs will be linked, then configure the Credentials service and test a program certificate for a learner who has completed the required courses. Output: a working program credential test with a documented list of Discovery dependencies, or a written decision that programs are out of scope.
Write the reissue and support runbook
Document how support staff verify a learner's certificate, how they reissue one after a name change or template correction, and when they escalate to the platform team. The runbook should name the roles that can trigger reissue, the steps to regenerate a certificate, and how the old record is handled. Walk the runbook through with the support team using the test learners from the earlier step. Output: an approved runbook for reissuing and verifying certificates, with the support team confirming they can follow it.
Run a controlled production launch
Promote the verified configuration to production through the same deployment path used for the test environment, then enable certificates for a limited set of pilot courses. Watch the first real issuances, check the stored records and confirm learners can download their files. Expand to the remaining courses once the pilot results match the test results. Output: a launch record listing the pilot courses, the issuance checks performed, the date each course was enabled and the owner who accepted the launch.
What drives certificate effort and how to keep it down
This table lists the main drivers of certificate effort in Open edX and how each one changes the work. Read each row as a decision to settle before the build starts. The main takeaway is that every template, language, program and catalog combination adds review and test work, so a smaller launch set keeps effort down.
| Driver | How it changes effort | How to keep it down |
|---|---|---|
| Organizations and languages needing templates | Each organization or language can have its own template, so each combination adds design, translation and review. | Start with one default template. Add variants only for organizations or languages that launch on day one. |
| Design and legal review of certificate wording | Wording needs approval for each template. Changes after learners hold certificates raise reissue questions. | Approve one master wording set. Run a single legal review cycle and record sign-off for each template. |
| Courses that show effort hours | Each course that displays hours needs a verified value and a check of how it renders on the certificate. | Agree who supplies hours and where they are stored. Check one sample course before filling in the rest. |
| Program structures and complexity | Programs depend on the course list and completion rules. Optional branches and overlapping requirements need more test cases. | Keep first programs linear. Write course lists and rules down before configuring the Credentials service. |
| Discovery and catalog readiness | Program certificates rely on Discovery catalog data. Missing or inconsistent course records block program issuance. | Confirm catalog records before template work. Ask the team for its plan for the legacy catalog, which is slated for removal in Willow. |
| Test enrollment volume | Each template, language and program path needs test learners who pass and receive a certificate. Counts grow with every combination. | Build a test matrix limited to launch combinations. Reuse a fixed set of test accounts across all paths. |
| Automatic or manual generation | Automatic generation reduces operator steps but needs more testing. Manual generation adds ongoing operator work for each batch. | Choose the mode per course type. Test the chosen path end to end on a staging site with the feature flag enabled. |
How certificates connect to the rest of the Open edX platform
A certificate is only as accurate as the data behind it. Course certificates depend on LMS enrollment and grading records, learner names depend on identity sources, and program certificates depend on the Course Discovery application and the Credentials service. Confirm each of these links in your own environment before you design templates or issuing rules.
LMS enrollment and grading data
Course certificates are triggered from the LMS once a learner's enrollment and grade meet the course's certificate rules. Check which certificate mode each enrollment uses, how passing grades are set, and whether grade changes after issue can re-trigger generation. Confirm the feature flag and generation mode (automatic or manual) in your own configuration, since this decides who or what sends a certificate.
Learner name from identity sources
The name printed on a certificate comes from the learner profile, which is often populated by third-party authentication. Open edX third-party authentication supports OAuth2 providers, SAML 2.0, Shibboleth and LTI, with older provisional support for CAS and SSL client certificates. Confirm which identity provider supplies the full legal name, how it maps to the profile, and what happens when a learner has no name recorded.
Course Discovery for programs
Program certificates depend on the Course Discovery application, which defines the programs and the courses within them. A program certificate can only be issued when Discovery data and LMS completions agree. Confirm that program definitions, course run identifiers and the catalog data your Credentials service reads are synchronized and kept current when courses are added or retired.
Tutor deployment and plugins
If your certificate templates, Credentials service or identity integrations are delivered as plugins, they must be carried in your Tutor deployment so they survive rebuilds and upgrades. Tutor is the official Docker-based distribution and supports plugins and hooks. Confirm which plugins are installed, which versions they target, and how they are rebuilt and tested before each Open edX release change.
Completion reporting through Aspects
If the organization reports on credential completion, Open edX Aspects can capture tracking logs as xAPI statements, store them in ClickHouse through Ralph or Vector, and present them in Superset dashboards. Confirm which events are emitted for certificate issue and grade changes, who can see the dashboards, and whether the reported counts match the certificates actually issued in the Credentials service.
Moving existing learners and certificates into the new setup
Before any learner data moves, the team needs a written answer to one question: which previously issued credentials must be reproduced in the new setup, and which can stay with the old platform or be re-issued later. A learner who completed a course on a legacy system and holds a certificate there is not automatically covered by a new LMS certificate configuration. Certificate records, the templates used to render them, and the course identifiers they reference all live in the source system, and each has to be mapped or deliberately left behind. Settle this with the platform owner and the people who answer learner support tickets, because they will be the ones asked why a certificate is missing.
Learner identity is the second question and usually the harder one. Open edX ties a certificate to a user account on the LMS, so a migrated certificate only appears for a learner whose account in the new system matches the person who earned it. Decide which attribute is the match key (for example, an institutional identifier, a verified email address or a username) and check how duplicates, changed email addresses and learners who registered twice will be handled. If identity comes from an external provider, confirm how that provider's user identifiers relate to the accounts being imported. Each unresolved match is a learner who will see no credential on day one.
Program membership is the third question. Program certificates in the Credentials service depend on the program definition, the list of qualifying courses and the learner's record of completing each one. When courses were restructured, renumbered or retired during migration, program rules can no longer match the historical records without manual reconstruction. Ask the team who owns each program definition, which courses count toward each program, and whether partial progress from the old system should count. Do not promise learners that their program progress carries over until those rules have been checked against real records.
The documented import formats, converters and migration commands for moving course content and platform data are described on the separate migration page, so this section does not repeat them. Use that page for the mechanics. Here the job is to settle scope. Ask the platform owner to confirm, in writing, which certificate records, identity links and program completions can be carried over, which can only be reproduced by issuing new credentials, and which will not be migrated at all. Only after that list exists should the team tell learners what continuity to expect, and it should state the exceptions in the same message.
Questions buyers ask before hiring help with certificates
How much does Open edX certificate setup cost and why?
Cost depends on the scope agreed in writing before work starts. For course certificates, the main line items are enabling the feature flag, designing templates for each organization or language, loading approved wording and brand assets, and testing issuance from end to end. Program certificates add the Credentials service, its database and hosting, and the catalog data it relies on. Ask each bidder to price discovery and design, template build, integration and testing, deployment into your environment, and handover as separate lines. Separate one-time work from recurring costs such as hosting, upgrades to later named releases, and support retainers. Ask what would change the quote, including the number of templates, languages, programs, and whether certificates are generated automatically or manually.
How long does Open edX certificate setup take?
Duration depends mainly on how many templates, languages and programs you need, and on how quickly your sign-off owners respond. A single course certificate with one approved template moves through configuration and testing faster than several organizations, several languages and a Credentials deployment. The most common delays are unapproved wording, missing brand assets, unclear rules for displaying hours of effort, and waiting for test learners to be enrolled. Ask for a written timeline with milestones for design approval, staging tests and production cutover. Also confirm early that access to your cloud accounts, data center or network is ready, because approvals for those environments often sit on the critical path. Your timeline should show who owns each dependency.
What must our team provide for certificate setup?
Your team supplies the decisions and materials only your organization can provide. These usually include certificate template wording for each course type and language, brand assets such as logos and signatures in usable formats, and course metadata such as course titles, organization names and hours of effort. You also need a set of test learners with enrollments in each state you want to test, and named sign-off owners for wording, legal text and go-live. Access to staging and production environments and to the identity provider your learners use is also required. Missing wording is a frequent blocker, so agree on one owner for it before work begins. Put each responsibility and due date in the statement of work so delays have a clear owner.
Can our internal team set up Open edX certificates alone?
Yes, an internal team can set up course certificates alone if it has operators who understand Open edX configuration, Tutor-based deployment and LMS administration. Course certificates are enabled through a feature flag and configured with templates, so the work is bounded. Program certificates are more demanding because they involve a separate Credentials service, its data, and its dependency on the Discovery application. Consider whether your team has the skills for template design, testing across languages, and upgrades to each named release. A partner is useful when internal staff lack the time, when you need fixed scope with written acceptance criteria, or when you want an independent review of the configuration before learners see it.
How do Open edX program certificates differ from course certificates?
Course certificates are issued by the LMS for completion of a single course. Program certificates recognize a set of courses completed under a program and are issued through the Credentials service. Course certificates are configured inside the LMS, with a feature flag, per-organization or per-language templates, optional display of hours of effort, and automatic or manual generation. Program certificates are documented in the Credentials repository and need program definitions that reference courses and their catalog records. The practical difference is ownership: course certificates stay within LMS configuration, while programs add a second service to deploy, back up, secure and upgrade. Decide early which credentials you need, because program rules shape your catalog design and testing plan.
Do program certificates need the Discovery service in Open edX?
Yes, program certificates depend on the Discovery application for program and course data. Program definitions reference courses that Discovery publishes, so the catalog must be working before programs can be built and tested. Plan Discovery and Credentials together, including data loading, program-to-course mapping and the Catalog micro-frontend. Open edX documents that the legacy catalog is planned for removal in the Willow release, so choose your catalog approach with that release in mind. Ask the implementation team which catalog version and database they will use, and how program data will be kept in sync with your course records. Test each program with a small set of enrolled test learners before enabling it for all learners.
What happens to Open edX certificates after go-live?
After go-live, certificates need ongoing checks rather than a single handover. Track issuance errors, template changes and learner requests for reissue, and confirm that certificates still render correctly after each Open edX upgrade and Tutor update. Plan a change process for wording, logos and signatures, because a change may require a new template version for each language. Define who owns certificate requests and who can approve template edits. Back up the databases that hold certificate records, and test restore procedures for Credentials as well as the LMS. If you use a support retainer, ask exactly what it covers, such as monitoring, upgrades to named releases, template changes and incident response, and confirm those terms in the written scope.
What should we check before learners receive certificates?
Check the feature flag state, template selection and generation mode before any learner receives a certificate. Confirm that automatic generation runs only after the passing rule is met, and that manual generation is limited to named staff. Verify that each organization and language resolves to the intended template, that hours of effort display correctly, and that any links learners receive work in your environment. Test with test learners covering passing, failing and retake cases. Compare the output against the signed-off design, including fonts, names and dates. Record the test results and keep them with the sign-off record so your compliance team can show what was tested. Independent auditors assess compliance, and DeployOpen can prepare the configuration and evidence they review.
How DeployOpen scopes and delivers certificate work
DeployOpen scopes Open edX certificates as a written piece of work covering course certificates in the LMS and program certificates through the Credentials service. We build and test templates, generation rules and the Discovery dependency inside infrastructure you control. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- The written scope names which courses and programs issue certificates, and which organizations and languages need their own templates.
- We confirm whether certificates are issued automatically, manually, or both, and who approves issuance.
- Program certificate scope includes the Credentials service and the Discovery application that programs depend on.
How we build
- Course certificate settings are enabled through the feature flag and configured in the site operator's deployment.
- Templates are built per organization or language, with hours of effort shown where the course requires it.
- Program certificates are configured in the Credentials repository and tested against the course catalog data they rely on.
How we hand over
- Handover covers configuration as code, template source files and a record of every setting changed.
- Operators receive runbooks for issuing, reissuing and checking certificates, and for template changes.
- Documentation states which Open edX release the certificate settings were verified against before go-live.
How we support
- Ongoing support for certificate templates and Credentials updates is available as a retainer after handover.
- Release changes that touch certificates are reviewed before upgrades, since only the latest named release is supported.
- Ask your team which release your site runs and when its next upgrade window opens.
