Let's Seal
Seal anything.
The open standard for proving any file is real: unaltered, sealed by a known certificate, and in existence by a certain date.
Website ·
The SEAL standard ·
Free web app ·
Quickstart ·
What it seals ·
How it works ·
Use cases ·
Developers ·
Self-host ·
Verify a document
SEAL is the open standard for proving any file is real. One sealed artifact, one way to check it, verifiable by anyone, forever. Seal with any conforming tool, and anyone can verify it with any other.
Let's Seal created that standard, SEAL, Sealed Evidence Anchored to a Ledger, and runs the free network and reference implementation that issues and verifies it. The standard is the backbone. Everything in this repository is built on it, and given away.
It is the Let's Encrypt of document proof. Let's Encrypt made paid TLS certificates obsolete. Let's Seal does the same for paid document seals, and like Let's Encrypt it is free, open, and run as a public-benefit project of a foundation, not a startup.
Authenticity is infrastructure. It shouldn't be for rent.
Use it, free
Three ways to seal, all free:
The hosted web app, app.letsseal.org. Free for anyone, in the browser, nothing to install. Seal a file, send documents out for signature (remote, in person, or with no email at all), and issue branded certificates and credentials.
The command line and API. sealbot for the terminal, plus a REST API and SDKs to build sealing into your own systems.
Self-hosted. Run the whole engine yourself, under your own certificate authority.
Verifying is always free and never needs an account, at verify.letsseal.org or offline on your own machine.
Free forever. No per-document fees, no paid seal.
Open source (Apache-2.0). The engine, the SDKs, and the standard itself.
What a seal proves
A SEAL proof establishes three things cryptographically, and states its boundary plainly:
Unaltered. The file has not changed by a single byte since it was sealed. Change one byte and the signature breaks.
Time. It existed by a certain date, anchored to Bitcoin through OpenTimestamps, with no trust in us.
Issuer. It was sealed by a specific certificate. Where an organisation has proven control of a domain, the seal carries that domain as a machine-checkable identity.
Every seal is also written to a public, append only transparency log (RFC 6962) with a Bitcoin anchored root, so the record of what was sealed is itself tamper evident and anyone can audit it.
That is the whole guarantee, complete and permanent. A seal proves integrity, time, and the issuing certificate. It is not notarisation, and it does not assert a person's real world identity. The identity feature binds an email that a provider verified at seal time, and the honest term for it is a provider verified email, which is exactly what it delivers.
What it seals
One standard, every kind of file, each in its own native format so any standard validator can check it. No bespoke tooling for the reader, and no dependency on Let's Seal to verify.
The seal is native to each format, so a sealed PDF is still a normal PDF that opens anywhere, a sealed image still shows everywhere, and a signed artifact still installs as usual. The proof rides along inside.
See it in action
Seal and verify from the command line:
The free public verification portal, verify.letsseal.org:
A public proof page: the plain-English verdict anyone can open, with the evidence behind it. Subject and signer details stay private until you upload the file:
The hosted app at app.letsseal.org does the rest: seal files, send documents out for signature (remote, in person, or with no email at all), and issue branded certificates and credentials.
Quickstart
Verify any sealed document, free and in the open, at verify.letsseal.org, or run the reference verifier yourself:
Seal a file through the hosted API with an organisation key:
Or from the command line:
SDKs for Python and TypeScript, plus the OpenAPI schema, live in sdk/.
What a proof looks like
Open a sealed file's proof page, or run the verifier, and you get a plain verdict backed by evidence anyone can reproduce:
The verdict is deliberately strict. A cryptographically valid signature from a certificate that does not chain to the pinned root is a forgery vector, and it is reported as unrecognised, never as a pass.
How a seal is made and checked
The life of a seal: made once, evidenced and anchored to the public ledger, served back, and checkable by anyone, forever.
Verify it yourself, free
Two checks, both independent of us. A seal carries everything needed to check it, so pin the published root once and then verify offline, anywhere, forever.
Root fingerprint (SHA-256): 02:68:6D:EE:20:67:31:C4:59:C1:7A:9F:58:36:7B:0B:0B:BA:5D:24:C6:85:D8:6D:1F:74:49:86:2D:C0:FE:BE, subject CN=Let's Seal Root CA, O=Let's Seal, C=GB. Download it at letsseal.org/api/root-ca.
PDF: any standard PAdES validator with the root pinned, or python spec/verify.py sealed.pdf sealed.pdf.ots.
Email and detached: openssl smime -verify -in message.eml -CAfile letsseal-root.crt · openssl cms -verify -inform DER -in file.sig -content file -binary -CAfile letsseal-root.crt.
Software and SBOM: the standard open artifact-signing tools verify the signature and attestation against the published root, reproducible on any machine.
Time: ots verify sealed.pdf.ots against Bitcoin.
Transparency log: fetch an inclusion proof at /api/log/proof?sha256=<hex> and check it against the signed tree head at /api/log/sth (RFC 6962). Consistency proofs at /api/log/consistency prove the log is append only.
The public transparency log
Every seal is written to an append only Merkle log (RFC 6962), the same structure browsers rely on for Certificate Transparency. The log's root is signed and itself anchored to Bitcoin, so:
anyone can prove a given seal is included in the log (an inclusion proof),
anyone can prove the log has never been rewritten (a consistency proof),
and the whole thing can be audited without trusting the operator.
It is the impersonation audit trail: if a certificate ever sealed something under a name it shouldn't have, the evidence is public and permanent.
Issuer identity
A seal always proves which certificate signed it. On top of that, an organisation can prove control of a domain (DNS record or a message to a controller address), and that domain is then bound into the signing certificate itself as a dNSName, so an off-platform verifier reads the identity straight from the certificate.
Organisations that have not verified a domain are shown as self asserted, never as verified.
A verified issuer's badge is the domain it controls, which is globally unique and cannot collide.
Abuse can be reported publicly, and an impersonating issuer can be suspended, which stops its keys and drops its verified badge.
This is domain control as identity, the same model the web took for TLS. It proves who controls the seal, not a person's legal identity, and it says so plainly.
The SEAL standard
Open to verify. Open to implement. Impossible to lock up.
SEAL is a published specification anyone can build on, see SPEC.md and letsseal.org/standard. The goal is one interoperable way to seal and verify any file, not a product to lock into. A SEAL proof is integrity, time, transparency, and optional verified-email attribution in a single self-contained artifact.
The signing service, the SDKs, and the reference verifier in this repository are the reference implementation. Anyone else is free to write their own, and a proof made by one implementation verifies under any other.
Use cases
The standard fits any file and any sector. Worked guides for the common ones, each with step-by-step instructions and live proofs:
Documents and law: Law & legal · Property & conveyancing · Compliance & audit · HR & corporate · Government & public sector
Government & public sector
Finance and professional services: Banking & lending · Insurance · Accounting & audit · Investment & asset management · Surveying & property reports
Investment & asset management
Surveying & property reports
Software and supply chain: Software supply chain · Procurement & supply chain · Manufacturing & trade
Procurement & supply chain
Regulated and specialist: Healthcare · Pharma & life sciences · Construction & engineering · Intellectual property · Education & credentials
Construction & engineering
Media and individuals: Media, journalism & creative · Individuals & freelancers
Media, journalism & creative
See them all at letsseal.org/use-cases.
Architecture
The engine is fully self hostable and carries no hosted only code paths. A single-user install runs the identical code the hosted service runs.
Self-host
Run the whole thing yourself, under your own certificate authority.
You can swap in a paid AATL or eIDAS .p12 later with zero code changes, if you want a reader's automatic green check for verifiers outside your own portal. The cryptographic guarantee is identical either way. Your verification portal is the trust anchor.
For developers
REST API (hosted or self-hosted), authenticated with an organisation API key:
Digest-only endpoints (/seal/detached, /seal/blob) never receive the file's bytes, only its SHA-256.
CLI: sealbot seal, sealbot verify, sealbot issue, sealbot anchor, sealbot watch. Install with npm i -g sealbot (or run npx sealbot); a self-contained Rust build lives in cli-rs/.
SDKs: hand-written clients for Python (sdk/python) and TypeScript (sdk/ts), plus the OpenAPI schema (sdk/openapi.json). Generate a client for any other language with sdk/generate.sh.
CI: seal build artifacts in a pipeline with the GitHub Action in ci/.
Repository layout
Mission
Authenticity is infrastructure. It shouldn't be for rent. Proving a file is real is a public good, like a padlock in a browser bar, and it should be free, open, and owned by everyone who relies on it. Let's Seal is run as a public-benefit project of a foundation, not a startup, so the standard can never be pulled back behind a paywall.
Licence
Apache-2.0, see LICENSE and NOTICE. The SEAL specification is free to implement.
Created and maintained by nsokin. Let's Seal is a project of Experimental Open Works.