Standards 9 min read 3 October 2026

PDF Digital Signatures Explained: How They Work, What They Prove, and When They Fail

A digital signature in a PDF is not an image of a signature — it is a cryptographic proof of identity and document integrity. This article explains exactly what a PDF digital signature contains, how viewers verify it, what the trust chain looks like, and the specific scenarios where apparently valid signatures are not what they seem.

When a PDF viewer shows a green checkmark next to "Signature is valid," it is making a specific technical claim — and most people do not know exactly what that claim is. A valid digital signature in a PDF means two things: the document has not been modified since the signature was applied, and the signature was created using a private key whose corresponding certificate was issued by a Certificate Authority that the viewer trusts. It does not mean the signer is who they say they are in the real world. It does not mean the document's content is accurate. It does not mean the signature is legally binding for your specific jurisdiction or transaction type. Understanding what a digital signature actually proves — and what it does not — is essential for anyone relying on signed PDFs in a professional, legal, or regulatory context. This article explains the complete technical mechanism: how the signature is created, what data it covers, how the certificate chain works, what Long-Term Validation (LTV) means, and the specific scenarios where a valid-looking signature is not what it seems.

What a digital signature actually is

A digital signature in a PDF is not an image of a signature. It is a cryptographic object — a block of data computed from the document's content using the signer's private key — stored in a /Sig field in the PDF's /AcroForm dictionary. The signature is computed in three steps: Step 1: Hash the document content — A hash function (SHA-256 in current implementations) produces a fixed-length digest of the document's byte content, excluding the signature value field itself (which is left empty during signing). The digest is a fingerprint: any change to a single byte in the document produces a completely different digest. Step 2: Encrypt the hash with the private key — The signer's private key, using RSA or ECDSA, encrypts the hash. The result is the signature value. Only the holder of the private key can produce this value. Step 3: Embed the signature — The signature value, the signer's certificate (containing the public key), and the certificate chain are embedded in the PDF's signature field. The signed byte ranges (the portions of the document covered by the signature) are recorded. Verification works in reverse: the verifier decrypts the signature value using the signer's public key (from the embedded certificate) to recover the original hash, then recomputes the hash of the document's byte content and compares the two. If they match, the document has not been modified. If the certificate chain traces to a trusted root CA, the identity claim is verified.

The certificate chain and trust model

A digital signature is only as trustworthy as the certificate used to create it. Certificates are issued by Certificate Authorities (CAs) — organisations that have verified the identity of the certificate holder before issuing the certificate. The trust model is hierarchical: Root CA — A small number of Root Certificate Authorities whose certificates are pre-installed in operating systems and browsers. Adobe Acrobat's Approved Trust List (AATL) maintains the root CAs trusted for PDF signing. The AATL is updated automatically by Acrobat and includes major commercial CAs (DigiCert, GlobalSign, Sectigo) and government CAs. Intermediate CA — Root CAs typically do not issue certificates directly to end users. They issue certificates to Intermediate CAs, which in turn issue end-entity (signer) certificates. The complete chain — signer certificate → intermediate CA → root CA — must be verifiable for the signature to be trusted. End-entity certificate — The certificate issued to the individual signer. Contains the signer's public key, their name (as verified by the CA during issuance), the certificate's validity period, and the intended uses of the key (key usage flags, extended key usage). When a viewer validates a signature, it builds the certificate chain from the signer's embedded certificate to a trusted root, verifying each step. If any step in the chain is missing, expired, revoked, or not trusted, the signature shows as invalid or unknown — even if the document has not been modified.

Revocation checking and long-term validation (LTV)

A certificate that was valid when the document was signed may be revoked before you verify it — because the private key was compromised, the CA discovered the identity was misrepresented, or the certificate was issued in error. Revocation checking determines whether the certificate was valid at the time of signing, not just at its nominal validity dates. Two revocation mechanisms exist: CRL (Certificate Revocation List) — The CA publishes a list of revoked certificate serial numbers, updated periodically. Verifiers download the CRL and check whether the signing certificate appears on it. OCSP (Online Certificate Status Protocol) — A real-time query to the CA's OCSP server that returns the revocation status of a specific certificate at a specific time. More efficient than downloading an entire CRL. The problem: if you try to verify a signature years after signing, the original CA may have shut down, the certificate may have expired, and the revocation data may be unavailable. This is the Long-Term Validation (LTV) problem. LTV embedding solves this by capturing the revocation responses (OCSP responses or CRL data) and timestamp tokens at signing time and embedding them in the PDF's Document Security Store (DSS). A viewer validating the document years later uses the embedded material rather than querying a potentially unavailable online resource. LTV embedding is part of the PAdES-LTV profile defined in ETSI EN 319 102 and is required for PDF/A-2 digital signatures. This issue was discussed at PDF Days Europe 2024 in the context of pandemic-era documents signed without LTV whose signatures were now failing verification.

Scenarios where valid-looking signatures are not what they seem

Self-signed certificates — A signer can generate their own certificate without any CA verification. The signature is technically valid (the document has not been modified) but the identity claim is unverified. Acrobat shows a yellow warning: "The identity of the signer could not be verified." Self-signed signatures prove document integrity but not identity. Incremental update bypass — PDF allows incremental updates: new content appended to the file without rewriting the original content. A signature covers the bytes that existed at signing time. An attacker can append new content after the signature — content that was not there when the document was signed — while the original signed portion remains valid. Viewers that only check signature validity without checking whether unsigned content was added can be fooled. This is the "Incremental Saving Attack" (ISA) documented in academic research by Müller et al. (2019). Shadow documents — Some PDF structures allow content to appear differently when viewed versus when printed. A signature over such a document may cover the "viewed" content while the printed content is different. Rigorous signature validation must check for these structural anomalies. Expired certificates without LTV — A signature created with a certificate that has since expired will fail verification as "certificate expired" unless LTV material was embedded at signing time. The signature was valid when applied; without LTV, that fact cannot be proven to a verifier looking at it years later.

Approval vs. certification signatures

PDF defines two types of signature: Approval signature — The standard signature type. Approves the document's current state. Multiple approval signatures can be added to a document. Each subsequent signature covers all previous content plus any additions since the previous signature. Certification signature (DocMDP) — A special signature applied by the document's creator that specifies what changes are permitted after signing. The /MDP (Modification Detection and Prevention) transform determines: no changes allowed (the document is locked); only form filling and signing allowed; or form filling, signing, and annotations allowed. Only one certification signature is permitted per document, and it must be the first signature. Certification signatures are used when a form sender wants to guarantee the document structure cannot be altered but recipients can still fill fields and sign. Most signed PDFs you encounter in professional contexts use approval signatures. Certification signatures are common in form distribution workflows — government agencies, banks, and insurance providers use them to distribute locked forms that recipients can complete but not structurally modify.

A valid PDF digital signature means the document has not been modified since signing and the signature was made with a certificate from a trusted CA. It does not automatically mean the signer is who they claim, the content is accurate, or the signature has the legal weight needed for your specific transaction. For high-stakes reliance on signed PDFs, verify the certificate chain, check for LTV embedding, confirm the certificate was issued by an appropriate CA, and understand which type of signature — approval or certification — was applied.

Frequently asked questions

What does "signature is valid" actually mean in a PDF viewer?

"Signature is valid" means: (1) the signed byte ranges of the document have not been modified since the signature was applied; (2) the signer's certificate traces to a root CA trusted by the viewer; (3) the certificate was not revoked at the time of signing (if revocation data is available). It does not mean the signer's real-world identity has been independently verified, or that no new content was appended after signing. See Digital Signature for the full glossary entry.

What is Long-Term Validation (LTV) and why does it matter?

LTV embeds certificate revocation data (OCSP responses or CRL snapshots) and trusted timestamp tokens inside the PDF at signing time. This allows the signature to be verified years or decades later even after the signing certificate has expired or the CA has gone offline. Without LTV, a signature becomes unverifiable once the certificate expires. LTV is required for PDF/A-2 digital signatures and is defined in ETSI EN 319 102 PAdES-LTV.

What is the difference between a digital signature and an electronic signature?

A digital signature is a specific cryptographic mechanism: private key + certificate + hash of document content. An electronic signature is a legal concept covering any electronic indication of intent — including drawn images, typed names, and click-to-agree. All digital signatures are electronic signatures; most electronic signatures are not digital signatures. See the contract signing guide for the practical decision framework.

Can a digitally signed PDF be edited?

Adding content after signing invalidates the signature if the viewer checks whether unsigned content was appended. However, PDFs allow incremental updates, and some viewers only check whether the originally signed bytes are intact — not whether unsigned bytes were added afterward. For critical documents, use a certification signature (DocMDP) with no-changes-permitted to prevent any modification, and use a viewer that checks for appended unsigned content. See the ISA vulnerability research at pdf-insecurity.org.

Try it yourself

Everything in this article can be done directly in the free PDFTheGuide editor — no account required.

Sign PDF Fill PDF form Redact PDF Open editor