How to Verify a Signed PDF (and Why Most People Get It Wrong)

A signed PDF is just a file. The signature is metadata inside that file. Whether the metadata means anything legal — whether the signature is genuine, the document untouched, the signer who they claimed to be — is something a verifier has to prove, not assume. The good news: the standards are mature, the verification is mechanical, and Adobe Acrobat does most of it for free. The bad news: 90% of recipients click "open," see a tick, and stop reading. That tick can hide an expired certificate, a missing timestamp, or a signature added after a tampered edit.

This is what verifying a PDF signature actually entails, in the order a properly built verifier checks.

ETSI EN 319 142

The European standard that defines what a compliant PDF signature must contain — published 2016, current revision 2024

ETSI Technical Committee on Electronic Signatures and Infrastructures

ISO 32000-2

The ISO PDF specification (2020). Section 12.8 specifies the byte-level structure of an embedded signature dictionary

ISO/IEC 32000-2:2020

independent cryptographic checks a verifier must pass before declaring a PDF signature 'valid'

Hash, certificate chain, timestamp, revocation status

The four checks, in order

A signature is not a single check. It is a stack of four checks, each producing a different kind of evidence. A verifier reports "valid" only when all four pass; "invalid" means one of them failed, and which one matters more than the headline.

Step 1

Document hash

The PDF's byte range (everything except the signature blob itself) is SHA-256 hashed. The recomputed hash must exactly match the hash sealed inside the signature. One byte changed since signing = mismatch = invalid.

Step 2

Certificate chain

The signing certificate is verified against a trusted root CA. Adobe ships a default list (Adobe Approved Trust List); enterprises add their own. If the chain doesn't lead to a trusted root, the signer is 'unknown.'

Step 3

Timestamp

An RFC 3161 timestamp token from a Time Stamping Authority asserts when the signature was applied. Without this, an attacker could backdate a signature to a moment when the certificate was still valid.

Step 4

Revocation status

The signing certificate must not have been revoked. Verifiers fetch a CRL (Certificate Revocation List) or check OCSP at the moment of validation. PAdES-LTV embeds this proof inside the PDF so it survives offline.

The PAdES baseline levels — pick the right tier

ETSI EN 319 142-1 defines four PAdES baseline levels. They are cumulative — each one includes everything in the level below it. The level a signature reaches determines what kind of attack it resists and for how long it stays verifiable.

PAdES baseline levels per ETSI EN 319 142-1. Higher levels add proof that survives over time. SahlSign produces PAdES-B-T by default — sufficient for legally binding signatures with a verifiable signing time.

Jurisdiction	Law	Cross-border transfer rule	Intensity
PAdES-B-B	Baseline B-B	Basic signature. Hash + certificate. No timestamp. Verifies only at moment of signing; certificate expiry breaks future verification.	Moderate
PAdES-B-T	Baseline B-T	Adds a qualified or recognised RFC 3161 timestamp at signing time. The signing instant is provable independent of the signer's clock.	Restricted
PAdES-B-LT	Baseline B-LT	Embeds the certificate chain and revocation data (CRL/OCSP) at signing time. Signature stays verifiable even after the CA goes offline.	Restricted
PAdES-B-LTA	Baseline B-LTA	Adds periodic 'document timestamps' on top of the existing signature. Designed for archive-grade preservation — provable for 10+ years against algorithm decay.	Strict

Validation result of "valid" with no qualifications is meaningful only when all four checks — hash integrity, certificate chain, timestamp, and revocation — produce a positive result. A green tick that omits any of these is misleading.

— The PDF-A Association's Signature Validation guide, 2020

What Adobe Acrobat Reader actually shows you

Acrobat is the gold-standard verifier because nearly every recipient on earth opens PDFs with it, and because Adobe Approved Trust List membership is what most production signing tools target. Here is the verification UI walkthrough — the steps every recipient should know.

Verifying a signed PDF in Adobe Acrobat Reader

Open the PDF and look for the blue banner at the top
"Signed and all signatures are valid" means all four checks passed against your local trust store. A yellow warning means at least one is qualified — usually that the signer's CA isn't in your trust list. A red banner means a check actually failed.
Click the Signature Panel (left rail) for the per-signature breakdown
Each signature lists the signer's name, the signing time, and the certificate fingerprint. Right-click a signature → Show Signature Properties for the full chain.
Check the timestamp source under Show Signature Properties → Advanced Properties
Look for "Signature is timestamped by [TSA name]." If it says "Signing time is from the clock on the signer's computer," the time is unreliable and the signature is degraded to PAdES-B-B.
Verify the certificate's issuer leads to a trusted root
Show Signature Properties → Certificate Details → Trust. The chain must terminate at a CA in either the Adobe AATL or the European EUTL. If it terminates at "Self-signed" the signature has no third-party attestation of identity.
Confirm the revocation status was checked
Certificate Details → Revocation tab. "Status: Valid" with a recent check time means the CA confirmed the certificate wasn't revoked. "Could not be determined" means your network blocked the OCSP/CRL request.
Click 'View Signed Version' to see the document as it existed at signing
This is the single most important step nobody takes. PDFs can have multiple signature revisions; later edits can append unsigned content. The 'signed version' is the byte-exact PDF the signature attests to.

What a "broken" signature actually means

Recipients see "signature invalid" and assume forgery. In practice, the most common failure modes are technical, not malicious. Each tells you something different about the document.

Alternative

Tampered document

The byte sequence hash doesn't match the sealed hash. Someone edited the PDF after signing — even an annotation or page rotation breaks this.

Document integrity hash mismatch
"This document has been modified since it was signed"
The signed version (View Signed Version) and the current version differ
Reject. Request the original from the sender.

Recommended

Unknown signer / certificate untrusted

The hash is fine. The certificate is fine. But the issuing CA isn't in your trust list. This is the most common failure — the signature works, the verifier just doesn't recognise the issuer.

Add the issuer to your trust list (Acrobat: Edit → Preferences → Signatures → Identities & Trusted Certificates)
For one-off recipients, accept the signature manually after out-of-band identity confirmation
For enterprise rollout, ship the trust list with your endpoint configuration so all employees auto-trust the CA
Don't just click "Always trust" without checking the certificate fingerprint matches what the signer published

Two failure modes with timestamps

Timestamp problems are subtler. Two scenarios cause real trouble months or years after signing:

Step A

No timestamp at all (PAdES-B-B)

The signature was applied with the signer's computer clock as the time. If the certificate expires next year, the signature becomes unverifiable next year — because the verifier can't tell whether it was signed before or after expiry.

Step B

Untrusted Time Stamping Authority

The timestamp exists but the TSA's certificate doesn't chain to a trusted root. Acrobat shows the signing time but flags it as 'not from a qualified TSA' — which weakens the eIDAS-aligned legal posture from AES to SES.

The cure for both is PAdES-B-T or higher. Use a Time Stamping Authority that publishes a root certificate in the Adobe AATL or the EU Trusted List, embed the timestamp token at signing time, and the problem doesn't surface.

A verifier you can run locally

For programmatic verification — bulk signature checks, automated compliance audits, court-discovery workflows — the EU Commission ships DSS (Digital Signature Service), a reference open-source implementation of every ETSI signature profile. It validates PDFs against the same logic Adobe Acrobat uses, exposes structured results (which check failed and why), and runs offline.

Programmatic verification options

EU DSS (open source, Java/REST)
The European Commission's reference validator. Implements the full ETSI signature validation algorithm and produces a detailed report with the exact reason for each failure.
Adobe Acrobat Pro DC — Action Wizard
For non-technical compliance teams. Build a one-click action that opens a PDF, validates the signature, and exports the verification report as JSON for audit.
SahlSign /verify/[documentId] endpoint
Every SahlSign-signed document carries a verify URL in the Certificate of Completion. Any party (not just the signer) can open it to see the audit chain, integrity hash, and TSA timestamp without trusting our UI.

The takeaway

A signed PDF is verifiable. It is not, by default, verified. The difference is the half-second a recipient spends looking at the signature panel — or the API call a procurement system makes to a DSS endpoint before disbursing payment.

The four checks (hash, certificate, timestamp, revocation) are mechanical and language-neutral. If you can read the verification report, you can defend the document in court. If you can't, you're trusting a tick mark you don't fully understand.

PAdES-B-T

What SahlSign produces by default. Every signed PDF carries an RFC 3161 timestamp from a EUTL-listed TSA, with the full byte-range hash sealed via /ByteRange and PKCS#7 detached SignedData.

src/lib/pdf-seal.ts in the SahlSign source

That means anyone — your counterparty, their lawyer, a regulator, a court — can open a SahlSign PDF in any Acrobat Reader install and produce the same verification result. No vendor lock-in. No "trust us" UI. Just the standard.