Security
How we make certificates tamper-evident
A credential is only worth as much as the guarantee behind it. This page sets out what that guarantee is, how it works, and where it stops. The last part is the part most security pages leave out.
Tamper-evident, not tamper-proof
Most platforms say "tamper-proof". It is the wrong word, and the difference between it and tamper-evident is the whole of what follows. Nothing stops somebody opening a downloaded certificate image in an editor and changing the name on it. What a digital signature guarantees is that the change becomes detectable, so the altered document can no longer pass as the one your organisation issued.
The distinction is practical rather than pedantic: it tells a verifier what to actually do, which is check the credential at its source instead of trusting the file in front of them. The QR code and the permanent verification link exist to make that the path of least resistance.
How a credential is signed
1. The record is put into canonical form
Seven fields define the credential: credential ID, recipient name, recipient email, award name, issuing organisation, issue date, and a format version. They are serialised into JSON with the keys in a fixed alphabetical order. Canonicalisation matters more than it sounds, because two JSON documents with identical content but different key order produce different bytes and therefore different signatures. Fixing the order means a verification performed years later reconstructs precisely the bytes that were signed.
2. The record is hashed
The canonical JSON is hashed with SHA-256, producing a 32-byte fingerprint. Change any field by any amount and the fingerprint comes out completely different. A middle initial does it. A single character of the organisation name does it.
3. The hash is signed with the issuer's private key
The fingerprint is signed using Ed25519 with the issuing organisation's private key. Each organisation has its own key pair, so a signature identifies which organisation issued the credential, not merely that it passed through this platform. The credential record stores the resulting signature, the algorithm, the identifier of the key used, and the time it was signed.
4. Anyone can verify with the public key
Verification reverses the process: rebuild the canonical record from what the page displays, hash it, and check the signature against the organisation's public key. This runs in the visitor's own browser. A server that merely asserted "verified" would be asking the visitor to trust us. Doing the check on their own device asks them to trust the mathematics instead, which is a much cheaper thing to ask.
Key custody
A signature scheme is only as strong as the handling of the private key. Each organisation's private key is held in Supabase Vault, encrypted at rest, and is never sent to a browser, embedded in a page, or included in any file a recipient downloads. Signing happens server-side; the public half is the only part that is published, because it is the only part a verifier needs.
Keys can be revoked and replaced. Because every credential records the identifier of the key that signed it, a compromised key can be retired and its credentials re-signed without calling an organisation's entire issuance history into question.
What this does not protect against
Stating the boundaries is part of the guarantee. A valid signature means the record is authentic and unaltered. It does not mean:
- That the holder is the named person. Anyone can forward a link. The credential supplies the claim. Confirming that the person in front of you is the person named on it stays the verifier's job.
- That the award was deserved. We can prove your organisation issued it. Whether your assessment was rigorous is your reputation, and no cryptography substitutes for it.
- That an edited image is harmless. A downloaded file can be altered like any image. The verification page shows the signed record, which is why a verifier should always check the link or scan the QR code rather than reading the document alone.
If you are assessing a certificate you have been handed, the guide to verifying a certificate online walks through the checks in order, including what to do when the credential is not on this platform at all.
Frequently asked questions
- What algorithm signs the certificates?
- Ed25519, a modern elliptic-curve signature scheme. The signed credential details are first hashed with SHA-256, and the resulting hash is signed with the issuing organisation's private key.
- Where are private keys stored?
- In Supabase Vault, encrypted at rest and never exposed to the browser or included in any page. Only the public key is published, which is all a verifier needs.
- What happens if a private key is compromised?
- The affected key is revoked, a new key pair is issued for the organisation, and credentials are re-signed under the new key. Because each credential records which key signed it, revocation is scoped to the affected key rather than invalidating an organisation's entire history.
- Does a valid signature prove the person is who they say they are?
- No, and no credential system should claim otherwise. It proves the record is authentic and unaltered since issuance. Confirming that the individual in front of you is the person named on the credential is identity verification, which is a separate step you still perform.
- Is the certificate image itself signed?
- The signature covers the credential record: recipient name and email, award, issuing organisation, issue date, and credential ID. It does not cover the pixels of the image. Editing a downloaded PNG changes the picture but not the signed record, so the verification page still shows the true details, which is what a verifier is asked to check against.
Issue credentials that answer for themselves
We will walk your team through the signing and verification flow in detail, including key handling and revocation.