Validating Digital Signatures in PDF

← Back to Blog

The Signature Validation Process

When Adobe Acrobat or another PDF viewer validates a digital signature, it performs a multi-stage verification process. Each stage must succeed for the signature to be reported as valid. Understanding this pipeline is essential for diagnosing why a signature shows a yellow warning triangle or a red cross rather than a green tick.

The process runs in this order: hash verification, certificate chain building, trust anchor check, and revocation status check. A failure at any stage causes the overall validation to fail, though Acrobat distinguishes between the document integrity check (did the content change?) and the identity check (can the signer be trusted?).

Step 1 — Hash Verification

When a PDF is signed, the signing application computes a cryptographic hash (typically SHA-256 or SHA-384) over the byte ranges of the document that are covered by the signature. This hash is then encrypted with the signer's private key to produce the signature value, which is stored in the PDF's signature dictionary. To verify, the validator recomputes the hash over the same byte ranges and decrypts the stored signature value using the signer's public key (extracted from their certificate). If the two hashes match, the document has not been altered since it was signed. If they differ, the document has been modified and the signature is immediately invalid regardless of certificate trust.

Step 2 — Certificate Chain Building

Every digital signature includes a signing certificate, which contains the signer's public key and identity information. Certificates are issued within a Public Key Infrastructure (PKI): a signing certificate is issued by an intermediate Certificate Authority (CA), which is itself certified by a root CA. To validate the signing certificate, the validator must build a complete certificate chain from the signing certificate up to a trusted root certificate — a process governed by the PKIX standard (RFC 5280).

Building the chain involves fetching any intermediate certificates that are not already embedded in the PDF or cached locally. Well-formed signatures embed all intermediate certificates in the PDF's signature dictionary to ensure the chain can be built offline. If an intermediate certificate is missing and cannot be fetched, chain building fails.

Step 3 — Trust Anchor Check

Once the chain is built, the root certificate at its top must be present in the validator's trust store. In Adobe Acrobat, this is managed through the Trust Manager (Edit > Preferences > Signatures > Verification > Trust Manager). Acrobat ships with its own Adobe Approved Trust List (AATL) and European Union Trusted Lists (EUTL), which are updated periodically via an online service. Certificates issued by CAs on these lists are trusted automatically.

If the root certificate is not in Acrobat's trust store, the signature will show as having an unknown trust status. The fix is to manually import the root (and any intermediate) certificates and mark them as trusted for certifying documents. This is done through the Trust Manager by importing the certificate file and setting the appropriate trust flags.

Step 4 — Revocation Status Check

A certificate can be revoked before its expiry date if, for example, the private key is compromised. The validator must check that neither the signing certificate nor any certificate in the chain has been revoked at the time of signing. There are two mechanisms for this.

OCSP vs CRL

OCSP (Online Certificate Status Protocol) is a real-time protocol defined in RFC 6960. The validator sends a request to an OCSP responder (a server operated by the CA) containing the certificate's serial number, and the responder replies with a signed status of "good", "revoked", or "unknown". OCSP responses are fast and targeted, but require network access to the CA's responder at validation time.

CRL (Certificate Revocation List) is the older mechanism. The CA periodically publishes a signed list of all revoked certificate serial numbers. The validator downloads the CRL and checks whether the signing certificate's serial number appears on it. CRLs can be large and are only as current as the last publication interval (often hours or days), but they work fully offline once downloaded and cached.

Both OCSP and CRL require network access at validation time unless revocation data has been embedded in the PDF in advance. If the validator cannot reach the OCSP responder or CRL distribution point and has no cached data, Acrobat will typically warn that revocation could not be checked rather than failing outright.

Long-Term Validation (LTV)

Certificates have expiry dates, and CAs eventually retire their root and intermediate certificates. A signature created in 2024 with a certificate that expires in 2026 would become technically unverifiable in 2027 because the certificate chain can no longer be validated — even though the document was legitimately signed when the certificate was valid.

Long-Term Validation (LTV) solves this by embedding all the information needed to validate the signature directly into the PDF at the time of signing. This includes the complete certificate chain, OCSP responses or CRL data confirming revocation status at the time of signing, and a trusted timestamp from a Time Stamping Authority (TSA). With LTV data embedded, the PDF can be validated years or decades later without any network access, because all the proof material is archived within the document itself.

LTV is a core requirement of the PAdES (PDF Advanced Electronic Signatures) standard, defined by ETSI in EN 319 102. PAdES defines several conformance levels: PAdES-B-B (baseline), PAdES-B-T (with timestamp), PAdES-B-LT (with long-term validation data), and PAdES-B-LTA (with archival timestamp). The LTA level adds a document timestamp over the entire LTV-extended signature, providing cryptographic proof of the state of the document and its validation data at that point in time. This is the highest assurance level and is required by many European legal and regulatory frameworks under eIDAS.

Common Reasons Signatures Show as Invalid

• Document modified after signing: Any change to content covered by the signature — including invisible changes made by some PDF optimisers — will break hash verification. Incremental saves and approved changes (such as filling a form field) should not invalidate a certifying signature if the certificate was set to allow them.
• Missing intermediate certificates: The signing application did not embed the full certificate chain. The validator cannot build the chain and reports an unknown trust status.
• Root certificate not trusted: The root CA is not in Acrobat's trust store. The document may be perfectly valid but Acrobat cannot confirm the signer's identity.
• Certificate expired: The signing certificate had already expired when the signature was applied, or there is no trusted timestamp to prove the document was signed while the certificate was still valid.
• Revocation check failure: The certificate was revoked, or revocation status could not be determined and Acrobat is configured to treat unknown revocation as invalid.
• Weak digest algorithm: The signature used SHA-1, which Acrobat and most validators now treat as untrustworthy. SHA-256 or stronger is required for a green valid status in modern Acrobat versions.

Adding Trusted Certificates in Acrobat

To trust signatures from a specific CA, open Edit > Preferences > Signatures > Verification > More, then navigate to the Trust Manager. Use the "Add to Trusted Certificates" option to import a root or intermediate certificate file (typically in DER or PEM format). When importing a root certificate, ensure you check "Use this certificate as a trusted root" and select the appropriate trust level — at minimum "Certifying documents" for validating signed PDFs. In enterprise environments, trusted root certificates can be distributed centrally using a Windows Group Policy or the Acrobat Customization Wizard, ensuring consistent trust settings across all workstations without manual per-user configuration.