Verifying a Verified by Vera certificate

What a certificate attests

A Verified by Vera certificate is a frozen snapshot of one check: the statements found in a document, the sources consulted, the literal quotations, the times of consultation and the hashes of what was assessed. Two things are attested: that the stated sources said what the certificate records at the stated time, and that the certificate has not been altered since IamVERA signed it.

It is IamVERA’s own declaration, not a qualified electronic signature or seal under eIDAS, and not legal advice. It shows that a source states something, not that the source is correct, and it is no judgement on the completeness of the document.

Four mechanisms, not one

A certificate page shows several things that look alike. They do different jobs.

• Digital signature (publicly verifiable). ECDSA P-256 with SHA-256 over the text in payload.txt. The key belongs to the certificate “IamVERA Seal Signing 2026”, issued by the offline IamVERA Seal Root CA. Anyone can check it with the published certificates.
• Timestamp (publicly verifiable). An RFC 3161 token from a time-stamping authority (DigiCert; non-qualified) over the SHA-256 of the signed certificate data. It shows that this exact data existed at that moment.
• Integrity seal (not publicly verifiable). The field seal with algorithm HMAC-SHA256 (method version hmac-sha256-nonqualified-1) is a check the issuing environment runs on itself with a secret that only that environment holds. It detects tampering in the issuer’s own storage. A third party cannot verify it and should rely on the signature and the timestamp.
• Signed link (access control only). The ?sig= part of the certificate address is an HMAC of the certificate number. It stops people from guessing certificate numbers. It is not part of the proof, and the live or withdrawn status is checked on every request, not stored in the link.

The signed payload

The signed text is the prefix IamVERA-seal-v1 and a line break, followed by one JSON object in canonical form: keys sorted alphabetically, no whitespace, undefined values omitted. The signing service refuses any text that does not carry the prefix, a certificate number (cert_ and 20 hexadecimal characters) and the issuer Vera, so the key cannot be used to sign anything else. The object contains:

• certificateId, lineageId, version, verificationId, sealedAt, issuer, the recipient (issuedTo, when set) and sealLevel (non_qualified);
• hashes: original (SHA-256 of the file as received), delivered (SHA-256 of the file as delivered, when there is one), analysedText (SHA-256 of the text that was assessed), evidenceTable (SHA-256 of the canonical list of statements with their sources and quotations) and documentShown (SHA-256 of the read-only text on the certificate page, when shown);
• counts: statements, checked, valid, unchecked (not assessed), notChecked (outside the assessment, such as opinions and advice), neutral (examined, but no source concerns exactly this matter: nothing shown, nothing refuted) and contested (valid, with a qualification from counter-evidence);
• statementsDigest: SHA-256 of the canonical statements, so the table on the page is bound to the signature;
• methodVersions: the versions of the method (engine vee-1.0, literal quotation check literal-match-1, assessors two-judges-perplexity-1, seal hmac-sha256-nonqualified-1);
• previousLogHash: the hash of the last entry in the issuer’s append-only log of that environment, each entry chained to the one before it. It shows the order of events inside the issuer’s log. The log head is not published, so outsiders cannot yet check the chain itself.

Keys and chain

The fingerprints are those published by the issuer at /vee/seal/keys.json on each environment, read on 23 October 2026. Compare them with the values on a certificate page before you rely on it. The public certificates (chain.pem, public-key.pem) are published under /vee/seal/ on each environment.

Check a certificate yourself

Download the files from the certificate page (payload.txt, verified-by-vera.sig, public-key.pem, vera-root.crt, vera-seal-chain.pem, verified-by-vera.tst, ca.pem), then:

# 1. the signature over the signed data
openssl dgst -sha256 -verify public-key.pem -signature verified-by-vera.sig payload.txt

# 2. the chain up to the published root
openssl verify -CAfile vera-root.crt vera-seal-chain.pem

# 3. the timestamp, using the stamped fingerprint shown on the page
openssl ts -verify -digest <stamped fingerprint> -in verified-by-vera.tst -token_in -CAfile ca.pem

To check your own copy of the document, compute shasum -a 256 on it and compare the result with hashes.original, or select the file on the certificate page: the hash is computed in your browser and the file is not uploaded. If anything does not match, do not trust the certificate and contact the sender.

These are the checks the certificate page itself describes. Step 1 is also run in your browser on the certificate page.

Replacement and revocation

• Expiry or replacement. A new signing certificate is issued by the same root (the root is used offline). Earlier certificates stay verifiable with the earlier signing certificate, which is kept public.
• Leaked signing key. The root withdraws the signing certificate and issues a new one. Certificates signed before the leak can be recognised by the time in their RFC 3161 timestamp.
• Leaked root. The trust anchor is lost: a new root, a new publication and new signatures.
• No revocation list. IamVERA does not currently publish a CRL or an OCSP service for the signing certificate. Withdrawal is announced through this page and the certificate status.
• Withdrawing a single certificate. Changing a document means withdrawing the certificate and publishing a new version; only one version per document is live. A withdrawn version is kept for audit and shows as withdrawn, optionally with a link to its successor.

How statements are assessed

A statement counts as valid only when: it is anchored literally in the document; its source was reachable and readable and is allowed by the source policy of the sector; the passage that supports it is found word for word in the source (checked in code, not by a model); and two assessors from different model families confirm that the passage supports the statement. In the default configuration these are Perplexity (Sonar) and Grok. If they disagree and neither failed, the assessment of Perplexity prevails. A statement is therefore valid if both confirm, or if Perplexity confirms when they disagree.

That rule is a decision rule, not a majority vote and not statistical independence. Models from different providers can share blind spots, and the certificate does not measure how often the assessors disagree. A failure of a search or an assessment is never recorded as neutral or “no source”; it blocks publication until the check is repeated.

What a certificate does not prove

• It does not show that a source is correct, only that it states what is recorded.
• Pages can change after the moment of consultation; that is why the quotation, the surrounding text and the hash of the moment of consultation are recorded.
• Statements outside the assessment (opinions, advice, details that concern only the document) are listed as such. They are neither confirmed nor refuted.
• A statement can be confirmed by a source on the issuer’s own websites. The certificate names every source, but it does not yet total the sources by class.
• The signature and the timestamp are not qualified under eIDAS and are not trusted by Adobe or browsers by default: whoever trusts IamVERA trusts the root published above.
• The log chain (previousLogHash) cannot yet be checked from outside.

Last updated: 23 October 2026