Verify a seal without a Sigill account

A proof you can only check with the vendor who sold it to you is not much of a proof. Everything sigill.ai produces — timestamps, PDF seals, detached seals — is an open ETSI/IETF standard artifact, and this guide shows the independent ways to verify one. None of them require a Sigill account; most don't require Sigill at all.

The quick way: our public verifier

sigill.ai/verify accepts any artifact — a sealed PDF, a file plus its .p7s or .jades.json, a .tsr timestamp token — and produces a full validation report: hash binding, signature validity, certificate chain and trust, timestamp qualification. Free, no account, no signup.

For automation, the same checks are exposed as public API endpoints (POST /seal/verify, POST /seal/verify-hash, hash-based so content need not be transmitted) — see the API reference.

Timestamps: OpenSSL, fully offline

An RFC 3161 timestamp token (.tsr) verifies with stock OpenSSL:

openssl ts -verify -in proof.tsr -data yourfile.pdf -CAfile tsa-ca-bundle.pem

That command needs no network and no Sigill involvement — just the file, the token, and the timestamp authority's certificate bundle. The verify page shows the exact commands, including where to fetch each TSA's bundle.

PDF seals: any PDF reader

A PAdES-sealed PDF validates in standard readers:

• Adobe Acrobat shows the signature panel with the seal, the timestamps, and long-term validation status.
• Linux readers (Okular, Evince) validate the signature via poppler. Two known poppler limitations, not seal defects: the issuing CA may show as "unknown" (poppler's trust store is separate), and archival document timestamps display as an unknown signature type (poppler has no RFC 3161 support yet). The command-line equivalent is pdfsig contract_sealed.pdf.

The reference validator: the EU's DSS

For the strictest independent check, the European Commission's DSS validator — the reference implementation of the ETSI validation algorithm — accepts uploaded artifacts and reports the exact signature format (e.g. PAdES-BASELINE-LTA), validity indication, and timestamp qualification against the EU trust lists. This is the validator we hold our own output to.

Detached seals: the pairing rule

CAdES (.p7s) and JAdES (.jades.json) seals are detached — verification always needs both the original file and the seal artifact, and the file must be byte-identical to what was sealed. If verification fails with a hash mismatch, the first suspect is a re-serialized or re-exported file, not a broken seal.

What "valid" tells you

A passing verification establishes three things: the content is byte-for-byte what was sealed (integrity), the seal was made with the named organisation's certificate (origin), and it existed at the embedded timestamp's time (existence) — with qualified timestamps carrying eIDAS evidentiary weight for that last claim. What it does not depend on is Sigill's continued existence: the artifacts are self-contained, which is the point of building on open standards.