How to verify a signed PDF — and read the verdict

A PAdES PDF ships with the signer's certificate, a digest of the signed bytes and — at B-T and above — an RFC 3161 timestamp token. Any PAdES-aware validator recomputes those facts from the file itself: Adobe Reader's signature panel, the European Commission's open-source DSS validator, or a plain OpenSSL call. Public verification of our own evidence packs needs no account.

The validator is not taking anyone's word. It re-hashes the bytes, checks the certificate chain, and re-checks the timestamp token's imprint — three arithmetic operations, not an opinion.

Content first: does the digest match the bytes actually in this copy? Any edit after signing breaks this check — the recomputed hash and the signed hash disagree. This is the article 26(d) property in practice: any subsequent change is detectable.

Identity second: the certificate inside the signature names the signer and chains to a certification infrastructure you already trust. A failed chain check does not mean the signature was forged — it means the tool found no trustworthy path from the certificate to a root it knows about.

Time third: the token's genTime comes from the authority's clock, in UTC — not from the signer's laptop. The PDF also carries a claimed signing time from the signer's own clock; if the two disagree materially, the authority's time is the one with a defensible source.

A satisfied verdict asserts the three facts above: the bytes are the signed bytes, the signer is a certified identity, and the signature existed no later than stated. It asserts none of the human context — the validator does not know whether the signer read or agreed to the terms. That gap is why the ceremony evidence (an audit trail) is always presented alongside the cryptography, not instead of it.

Certificates expire, and the revocation responses (OCSP/CRL) that let a validator check a chain's status are served by systems that do not answer forever. A B-T file proves a lot on the day it is signed; years later, the tool may fail to re-establish the whole chain — not because the proof weakened, but because part of the supporting data is no longer retrievable.

This is the known answer to a known problem: B-LT embeds the validation material — chain and revocation information — inside the PDF itself, so the evidence needed at verification time travels with the document. If the proof must outlive expires of the certificates that produced it, ask the signer's platform for B-LT before it is needed; our guide to B-T, B-LT and B-LTA has the details.

The timestamp side is defined by RFC 3161 — the imprint in a response must match the request, the token must carry a serial unique to that authority, and the time must be UTC. The validation algorithms and profile are set in ETSI EN 319 102-1 and EN 319 142-1 — named here, not reproduced, since both are paywalled ETSI standard texts.

One more check anyone can run with the naked eye: the signature covers the whole document. Add a page, a stamp, or a text box after signing and the covering byte range no longer matches — every tool above will say so.