Who Owns Your Certificates? Self-Hosted Training Certificate Generation, Honestly Compared
A hosted verification URL is a dependency. Cryptographic badges are a standard. A self-hosted verify page is a third thing. Here are all three trust models compared honestly, including where the self-hosted one is the wrong choice.
If you run training, you issue certificates. And at some point somebody asks the only question that matters about them: how does an employer know this is real?
There are exactly three answers in use today. Most articles about certificate software only describe one of them, because they are written by a vendor selling it. This one describes all three, including the one we do not sell.
The objection first, in a competitor's own words
Here is the strongest argument against generating your own certificates, and it comes from a hosted credentialing vendor:
"anyone can edit a PDF, which is why employers and authorities often question self-made certificates."
That is correct. A PDF is a picture of a claim. Anyone with a text editor and ten minutes can change the name, the date, or the grade on one. If your certificates matter — if they gate employment, licensing, or insurance — a bare PDF is not evidence and you should not treat it as one.
Everything below is about what you bolt on to fix that.
Model 1 — The hosted verification URL
This is what most credentialing platforms sell. Each certificate carries a unique code and a link to a page on the vendor's domain. An employer clicks it, sees the vendor's page confirming the credential, and is satisfied.
Why it works: the verifying page is served by a neutral third party. That is genuinely stronger than a document you produced yourself, for the same reason a reference from a former employer is stronger than a reference you wrote.
What it costs you, beyond money: the verification of your certificates now depends on somebody else's business continuing to exist, at their prices, on their domain. The certificate you issued in 2026 is verifiable in 2032 only if that vendor is still running that URL.
That is not hypothetical. It is the ordinary lifecycle of software companies — acquisition, sunset, migration, re-pricing. If your training records need to outlive your vendor relationship, this model has a dependency in it that nobody mentions at signup.
Model 2 — Cryptographic, standards-based credentials (Open Badges)
The serious answer to both problems above. Under the Open Badges specification (read 2026-08-01), a credential carries its own cryptographic proof, so verification does not depend on the issuer's servers being up.
The spec is explicit that this is the point:
"Portability and learner data privacy are improved by expanding the usage of cryptographic proofs/signatures, because this format will be compatible with a growing array of proof schemas."
And credentials "can be easily bundled into Comprehensive Learner Records and Verifiable Presentations" — meaning the recipient can hold and present them independently of whoever issued them.
If you need certificates that are verifiable in twenty years by someone who has never heard of you, this is the correct model and you should use it. Several hosted platforms implement it; some open-source badge issuers do too.
Model 3 — A verification page you own
The third model: you generate the certificates, you assign each a unique code, and the verify page runs on your domain, backed by your database.
Certora is this — a self-hosted certificate generator with templates, CSV import, batch PDFs with unique codes, and a public verification page. $34.00, one time (product page, read 2026-08-01).
And here is where we are going to be more honest than is comfortable. From Certora's own FAQ, quoted verbatim:
"Is the verification cryptographic?" — "No, and it doesn't need to be — a verification code is a random, database-unique lookup token. Verification is a lookup against your own register, not a signature check. Nothing is signed or encrypted."
So Model 3 is not Model 2. A Certora certificate is not an Open Badge, carries no cryptographic proof, and is not portable in the sense the standard means. If a buyer needs standards-based verifiable credentials, this is the wrong product, and any page that blurs that line is misleading them.
What Model 3 actually changes is the direction of the dependency. Model 1 makes your certificates depend on a vendor. Model 3 makes them depend on you — your domain, your database, your uptime. That is not automatically better. It is better only if you expect to outlast your vendor, and worse if you do not.
The comparison, stated plainly
| Model 1 — hosted URL | Model 2 — Open Badges | Model 3 — your own verify page | |
|---|---|---|---|
| Employer can verify | ✅ on vendor's domain | ✅ cryptographically, anywhere | ✅ on your domain |
| Survives the vendor closing | ❌ | ✅ | ✅ (if you survive) |
| Survives you closing | ✅ | ✅ | ❌ |
| Standards-based portability | usually | ✅ | ❌ |
| Recurring cost | yes | varies | no |
| Who is trusted | the vendor | the maths | you |
Read the bottom row. That is the whole decision. Every model requires trusting somebody; they differ only in who.
What the self-hosted version does well
Since we have been clear about what it is not, here is what it is — from the product page (read 2026-08-01), quoted rather than summarised:
- Codes cannot collide. "Codes are random and enforced unique at the database level; batch generation is tested collision-free at 1,000 certificates."
- The verify endpoint is hardened. "The verify endpoint has a honeypot, per-IP rate limiting, and returns 404 on a miss — and a code exposes nothing beyond what's on the certificate face." The 404-on-miss detail matters: it means the page cannot be used to enumerate who holds a certificate.
- Revocation is immediate. "Revoke or reinstate any issued certificate from the register; the public verify page reflects it immediately." This is the feature most self-built solutions forget, and the one you will need the first time someone's certification lapses.
- It runs on ordinary hosting. "PHP 8+ with PDO, MySQL/MariaDB or SQLite, a 2-minute web installer, no Composer packages, no API keys."
Who each model is actually for
Choose Model 1 (hosted platform) if your certificates need third-party credibility, you have no interest in running infrastructure, and a monthly fee is acceptable. Most professional bodies should be here.
Choose Model 2 (Open Badges) if credentials must be portable, machine-readable, and verifiable long after any particular relationship ends. Universities, accreditors, and anyone issuing credentials that feed into a formal learner record belong here. This is the technically strongest option and we do not sell it.
Choose Model 3 (self-hosted) if you issue a moderate volume of certificates for internal or low-stakes purposes — course completion, staff training records, workshop attendance, membership — where the audience is your own organisation or people who already trust your domain, and where the alternative you are actually comparing against is emailing a PDF with no verification at all.
That last clause is the honest framing. Model 3 is not competing with Open Badges. It is competing with a Word template and a mail merge — and against that comparison, a unique code, a register, revocation, and a verify page is a large improvement for one payment.
The honest costs
Your domain becomes load-bearing. If you let it lapse, every certificate you ever issued becomes unverifiable. This is the single biggest risk in Model 3 and it is entirely within your control — set the domain to auto-renew for ten years and treat it as a records-retention decision, not an IT one.
Your uptime becomes the verification's uptime. If an employer checks a code while your server is down, they see nothing. Model 1 has a team on call for this. You do not.
Backups are the certificate register. Losing the database does not lose the PDFs — recipients still hold those — but it destroys the ability to verify any of them. Back up the database, and restore it once as a test before you trust it.
Hosting. Plain PHP and MySQL or SQLite; if you already run a site, the marginal cost is often zero. For a concrete number from a named provider: Hetzner's own pricing — machine-read from the price API behind their pricing pages on 10 Aug 2026 — lists web-hosting plans from €1.60 to €16.72 a month and entry cloud servers from €3.99 a month (prices as returned for their German datacenters; confirm current pricing and VAT treatment at checkout). Any comparable host works — the point is that the "own" side of this comparison costs single-digit euros a month.
The switch path
1. Try the demo. The Certora demo opens already signed in on sample data with no sign-up, and resets itself. Issue a certificate and verify it — that round trip is the entire product.
2. Decide your model before your tool. Use the table above. If you land on Model 2, stop here; this is not your product.
3. Set the domain to long auto-renew before you issue a single certificate. This is step three because it is not optional.
4. Import a past cohort as a test. Generate, verify, revoke one, verify again. Confirm the 404 behaviour on a made-up code.
5. Write down where the register is backed up, and put that note somewhere a successor will find it. A verification system nobody knows how to restore is a verification system with an expiry date.
The short version
A PDF alone is not evidence — the competitor quoted at the top of this article is right about that.
Fixing it means choosing whose word an employer takes: a vendor's, mathematics', or yours. If the answer is "mathematics," use Open Badges and ignore everything we sell. If the answer is "the vendor," pay the subscription; you are buying neutrality and it is worth money.
If the answer is "ours" — because the certificates are internal, the audience already trusts your domain, and the realistic alternative is an unverifiable email attachment — then a generator with a unique-code register and a verify page you own costs $34 once, and the dependency you take on is your own domain rather than somebody else's business model.
Next steps
- Open the live Certora demo — issue one, verify one, no sign-up
- Certora product page and licence options
- Self-hosted alternatives by category
The Open Badges specification is linked and quoted above so you can check our characterisation of it. We do not implement it, and we would rather tell you that here than have you discover it after purchase.