How to validate a digitally signed PDF

A digitally signed PDF is a document carrying a PAdES signature — the ETSI EN 319 142 standard for embedding an advanced electronic signature directly inside a PDF's own structure, rather than as a separate file. To validate one, a validator has to confirm four things: the signed bytes have not changed since signing, the certificate chains to a trusted root, the certificate was not revoked, and — where a trusted timestamp exists — that the signature is anchored to a specific point in time. Opening the file and seeing a signature panel is not validation; none of those four checks happen automatically in a PDF viewer's default view.

This matters because "digitally signed" and "validly signed" are not the same claim. A PDF can carry a signature, a certificate, and a signature panel that looks correct, and still fail every one of the checks above.

What "signed" actually means inside the PDF

A PAdES signature lives in the PDF's own byte structure — a /Sig dictionary referencing a SignedData object (the CMS/CAdES structure that PAdES adapts for PDF) and a byte range covering the content that was hashed at signing time. Because the signature is embedded rather than wrapped around the file, a signed PDF opens in any ordinary PDF reader; nothing about the container format signals that validation still has to happen.

Adobe Reader and similar viewers do run a basic check and show a badge — a blue ribbon, a checkmark, a warning triangle — but that badge reflects only what the viewer's own (often outdated or non-EU) trust store knows. It does not confirm the signature meets eIDAS's advanced or qualified thresholds, and it will not catch a certificate that chains to a trust anchor the viewer's default store doesn't carry — which is the normal case for an EU qualified certificate.

The four checks a real validation performs

Integrity. The validator recomputes the hash over the byte range covered by the signature and compares it to the signed hash. If a single byte inside that range changed after signing, this fails immediately — everything downstream is moot.

Chain. The signing certificate has to build a chain to a trusted root. For a PDF signed under eIDAS, that root is a certificate authority listed on a national trusted list, indexed by the EU List of Trusted Lists. A self-signed certificate, or one issued by an authority not on any trusted list, breaks the chain here.

Revocation. The certificate must not have been revoked at the relevant point in time, checked via OCSP or a CRL. This is a live check against the issuing authority — it is not something baked into the PDF at signing time, unless a revocation response was itself embedded as part of a long-term (LT/LTA) signature.

Time. If the signature carries a trusted timestamp, the validator can confirm the signature existed before a specific moment — which matters when a certificate expires after signing. As Sealium's own validation reports state it: an expired certificate is not automatically invalid; the timestamp decides. Without a trusted timestamp, a validator can only say the signature was valid *as of the check*, not as of signing.

A result is only "valid" if all four hold. Standard result enums — TOTAL_PASSED, INDETERMINATE, TOTAL_FAILED — exist precisely because real documents often land in the middle: a technically valid signature attached to a certificate whose status can't be fully resolved, for example.

Three ways to run this check

A PDF viewer. Adequate for a quick look, not for anything an auditor or regulator will ask about later. The trust store is the viewer's, not the EU's, and there is no structured report to keep as evidence.

EU DSS, self-hosted. EU DSS (esig/dss) is the reference implementation of the ETSI validation algorithm and is excellent, open-source software. Running it yourself means instantiating a PAdESService, maintaining your own trusted-list refresh against the LOTL, and decoding the Indication/SubIndication output into something a non-engineer can read. This is a reasonable choice if you're validating a single format inside a Java codebase you already control.

A validation API. For everything else — multiple formats, a non-Java stack, or a report that has to stand up in an audit — a hosted API collapses the above into one call: send the document, get back who signed it, when, with what certificate, and at what eIDAS level (QES, AdES or SES), as structured JSON.

``bash curl -X POST https://api.sealium.eu/v1/validate \ -H "Authorization: Bearer slm_live_xxxxxxxxxxxxxxxxxxxx" \ -F "file=@contract.pdf" ``

The document is processed in memory and never stored — only the report is persisted. Sealium's API runs exactly the four checks above against the live EU trusted lists, and the free tier covers 100 validations a month with no credit card.

What a validation report should tell you

Whichever route you take, a complete result answers the same questions: who signed (the certificate's subject), when (signing time, and separately, timestamp time if present), with what certificate (issuer, validity period, qualification statements), and what the signature level is — SES, AdES or QES. If the tool you're using can't answer all four for a given PDF, treat the result as incomplete rather than as a pass.

FAQ

Does a green checkmark in Adobe Reader mean the signature is valid? Not on its own. It means Adobe's viewer resolved the certificate against its own trust store, which is not the same as an EU trusted-list check. A signature can show a valid badge in a viewer and still fail eIDAS-level validation, or vice versa if the issuing authority isn't in Adobe's default store.

Can a digitally signed PDF be edited after signing? Any change to the bytes covered by the signature's byte range breaks the integrity check and invalidates the signature. PDF supports incremental updates that can add content outside that range (for example, a second signature) without breaking the first one — which is by design, not a flaw.

What is the difference between PAdES, CAdES and XAdES? All three are implementations of the same AdES signature model for different content — PAdES for PDFs, CAdES for arbitrary binary via CMS, XAdES for XML. PAdES is essentially CAdES adapted to live inside a PDF's own structure.

Is a self-signed certificate ever valid for a digitally signed PDF? It can produce a technically valid signature (integrity holds), but it cannot reach AdES or QES status, because those levels require a chain to a trusted root. A self-signed certificate proves the document wasn't altered after signing — nothing about who signed it.