Verify a signed report without asking us.
Paste the attestation that came with an Attestkeep compliance report and the installation's licence certificate, and the whole chain is checked right here in this tab — against our signing key, which is built into this page. You enter no key, and no request leaves the page: the verdict cannot depend on us being reachable, honest, or in business.
Run the check
You need two things, both delivered alongside the report: the attestation file — a small
.json document called a DSSE envelope — and the installation's licence
certificate, a three-part token signed by Attestkeep. Paste each one or pick the files,
then press verify.
The chain, link by link
- Certificate — signed by the Attestkeep root key
- Envelope — signed by the installation's evidence key
- Match — report and certificate name the same installation
Verified
The signature checks passed. Everything below is read from the verified documents themselves.
Verified against a hand-entered key. This shows the document is consistent with that key — it does not establish which installation the key belongs to. Only the certificate chain can do that.
The signature is genuine, but the predicateType below is not the compliance evidence type. Whatever this statement attests, it is not an Attestkeep compliance report.
Licence certificate
- kid
- licence
- plan
- fingerprint
- valid until
Report attestation
- keyid
- predicateType
- subject
- subject sha256
- report_id
- framework
- period.start
- period.end
- fingerprint
- generated_at
- generated_by
- generator
The subject digest is the SHA-256 of the report file this attestation is about. To tie
the attestation to the copy in your hands, hash that copy — sha256sum
report.json — and compare it with the digest above. If they match, the report
you hold is, byte for byte, the one that was signed.
Not verified
Reason:
This pairing may have been altered or mismatched, and nothing on this page vouches for anything it says. Do not treat it as evidence. A failure can also have innocent causes — a truncated copy, a certificate that belongs to a different installation than the report, a file that is not the envelope — so check those first, then ask the installation's operator for a fresh copy of both.
Where the key comes from
You do not enter one. The page carries the only key you are asked to trust — ours:
kid: ak1
ed25519: e287aabe4712197cfa5b6fdf9ea8f2d7f0333ce16ca69aac7e4a3f1e84c04179
Everything else is vouched for in a chain. The licence certificate is a document we sign
with that key; inside it, the cnf.jwk field names the evidence signing key of
the licensed installation. That key signs the DSSE envelope, and the envelope's digest
pins the report. The page also cross-checks that the certificate and the report name the
same cluster fingerprint — without that step, a genuine certificate could be laid next to
a genuine envelope from some other installation, and the pair would look like proof.
The chain exists because the old way had a hole in it. A verifier that accepts a public key from whoever brought the document proves only that the document is consistent with itself: a forger mints a key pair, signs an invented report, and hands you both. The chain replaces "the key the report's author handed you" with "the key we certified for that installation" — one trust anchor, held by a party with no stake in the report's contents.
The manual-key path under the form is exactly that weaker check, kept for a reader who has an envelope but no certificate. Its result carries the caveat with it.
What a pass proves — and what it does not
A green result above proves exactly two things:
- the documents have not changed since they were signed — alter one character, even inside a timestamp, and the check fails;
- the report came from the installation our certificate names — its envelope was signed by the key the certificate vouches for, and both name the same cluster.
It does not prove more than that, and the two limits are worth stating in full:
It is not a legal electronic signature. No qualified certificate is involved and no e-signature statute — eIDAS in the EU, Law 5070 in Türkiye — applies to it. It is a cryptographic integrity check. If your process requires a legally recognised signature, this does not substitute for one.
It does not prove when the document was signed. The
generated_at timestamp and the audit period are the installation's own
declaration, read from its own clock. No timestamping authority is involved, so a signature
made today over yesterday's date would verify just the same. If you need the time proven,
that proof has to come from somewhere else.
One more honest line: the signature vouches for the document, not for the world. It proves the report is exactly what that installation produced — not that the events the report describes happened as described.
Nothing leaves this page
The verifier is ordinary JavaScript served from this site — the hashing and the Ed25519 arithmetic included, with no third-party library and no CDN. You do not have to take that on faith: open your browser's network panel and watch while you verify, or load the page, disconnect from the network entirely, and verify offline. The result is the same, because neither document is ever transmitted.
The format — every predicate field, the envelope shape, the certificate, the encoding that gets signed — is specified in the compliance evidence attestation, v1, which also carries a real signed example to try against this page.
Last updated: 29 August 2026