Security 10 min read 22 October 2026

PDF Digital Signature Revocation: OCSP, CRL, and LTV Explained

A PDF digital signature is only trustworthy if the signing certificate has not been revoked. This guide explains how OCSP and CRL revocation checking works, why signatures fail after certificate expiry, and how Long-Term Validation (LTV) enables signature verification decades into the future.

A PDF digital signature proves that a document was signed by the holder of a specific private key and has not been altered since signing. But the trust model has a critical gap: a signature is only meaningful if the signing certificate is still valid. If a certificate is revoked — because the private key was compromised, the holder's employment ended, or the CA made an error — every signature produced with that certificate becomes untrustworthy, regardless of when it was created. This is not a theoretical concern. Certificate revocation is a routine event in enterprise PKI: staff leave organisations, keys get compromised, hardware tokens fail, and CAs revoke certificates in response to incidents. A PDF archive that was correctly signed at creation time can silently become unverifiable years later if revocation information is not preserved alongside the signature. This guide explains how OCSP and CRL revocation checking works, why the standard online-checking model breaks for long-term archives, and how Long-Term Validation (LTV) signatures solve the problem by embedding all necessary revocation data inside the PDF at signing time.

How certificate revocation works: CRL and OCSP

Every certificate issued by a Certificate Authority (CA) can be revoked before its expiry date. Two mechanisms exist for checking whether a certificate has been revoked: Certificate Revocation Lists (CRL) — A CRL is a signed list of revoked certificate serial numbers published by the CA at a URL embedded in the certificate's CDP (CRL Distribution Point) extension. PDF viewers and signature validators download the CRL from this URL and check whether the signing certificate's serial number appears. CRLs are updated on a schedule (typically every 24 hours for large CAs) and can be cached by the client. A CRL for a major CA can be several megabytes and contain hundreds of thousands of entries. Online Certificate Status Protocol (OCSP) — OCSP provides real-time revocation status for a single certificate. The validator sends a request to the OCSP responder (URL in the certificate's AIA extension), and the responder returns a signed status response: good, revoked, or unknown. OCSP responses are smaller and faster than CRL downloads and provide more current status. The OCSP response itself has a validity period (typically a few hours to a day). OCSP Stapling — A server-side variant of OCSP where the TLS server includes a cached OCSP response in the TLS handshake, reducing latency. Not used in PDF signing, but analogous to LTV embedding. Revocation checking in PDF signature validation — When a PDF viewer validates a signature, it typically fetches revocation information online using the URLs embedded in the certificate chain. This requires internet connectivity at validation time. If the validator cannot reach the CRL or OCSP endpoint, many validators will report a warning or fail validation entirely, depending on configuration.

The long-term validation problem

The online revocation checking model has a fundamental problem for archival signatures: revocation information has a finite lifetime. CRLs expire when their nextUpdate date passes; OCSP responses expire within hours or days. Ten years after signing, the original OCSP response is long expired, the CRL that contained revocation status at signing time may no longer be available, and the CA that issued the certificate may itself no longer be operating. This creates a paradox: a PDF signed in 2015 with a certificate that was valid in 2015 might fail validation in 2025 — not because anything was wrong in 2015, but because the evidence of good status at signing time was never preserved. Timestamp certificates add another dimension. PDF signatures typically include a countersignature from a Timestamp Authority (TSA), which proves when the signature was created. But the TSA certificate can also be revoked, and the TSA's CA certificate has its own revocation chain. Chain revocation — Every certificate in the chain from the end-entity certificate to the root CA needs revocation checking. For a typical enterprise certificate, this chain may be three or four levels deep: End-entity → Intermediate CA → Root CA. Each link in the chain has its own CRL/OCSP endpoint. The entire chain must be checked at validation time. See PDF Digital Signatures Explained for the trust chain structure.

LTV: embedding revocation data inside the PDF

Long-Term Validation (LTV) is the PAdES standard solution (defined in ETSI EN 319 102 and formalised in PDF 2.0) for archival signatures. Instead of relying on online revocation checking at validation time, an LTV-enabled signature embeds all necessary revocation data directly inside the PDF at signing time. The LTV data is stored in the PDF's DSS (Document Security Store) dictionary — a dictionary added to the document catalog by the signing tool immediately after creating the signature. The DSS contains: /VRI (Validation-Related Information) — A dictionary keyed by the SHA-1 hash of each signature. Each VRI entry contains arrays of certificate, OCSP response, and CRL objects for that specific signature. /Certs — All certificates in the validation chain (end-entity, intermediate CAs, root CAs, TSA certificates). /OCSPs — The raw DER-encoded OCSP responses obtained at signing time, while the certificate was known to be valid. /CRLs — The raw DER-encoded CRL (or relevant CRL fragment) that was current at signing time. With this data embedded, a validator can verify the signature's full trust chain years later without making any network requests — the proof is self-contained in the PDF. This is the PAdES-LTA (Long-Term Archive) profile, which also adds a document timestamp over the DSS to prove the LTV data was present at a specific time. Adding LTV after signing — LTV data is added as an incremental update to the signed PDF. The original signed byte range remains intact; only new objects are appended. This is why PDF signature validators check whether the incremental update added only DSS data (legitimate LTV extension) or also modified signed content (a potential signature attack). Tools like pyHanko and iText support generating LTV-enabled signatures and adding LTV data to existing signatures.

PAdES signature profiles and LTV levels

The PAdES (PDF Advanced Electronic Signatures) standard, defined by ETSI, specifies a progression of signature profiles with increasing long-term validity: PAdES-B-B (Baseline) — A basic signature with certificate and timestamp. No revocation data embedded. Suitable for short-term use where online checking is always available. PAdES-B-T (Timestamp) — Adds a document timestamp from a TSA. Proves the signature existed at a specific time, which enables revocation checking to be anchored to that time. PAdES-B-LT (Long-Term) — Adds the DSS with full certificate chain and revocation data. Enables validation without network access. PAdES-B-LTA (Long-Term Archive) — Adds a document timestamp over the LTV data, creating a cryptographically sealed timestamp over the entire validation evidence. Also supports periodic re-timestamping as signature hash algorithms approach end-of-life — the document can be re-timestamped with a newer algorithm before the old timestamp's algorithm is broken, extending the valid period indefinitely. eIDAS qualified signatures require at least PAdES-B-LT for qualified electronic signatures under EU Regulation 910/2014. Many European enterprise and government contexts require PAdES-B-LTA for archival. See PDF Signatures vs E-Signatures for the eIDAS legal framework.

Frequently asked questions

What does it mean when Acrobat shows "Signature validity is unknown"?

This status means Acrobat could not build a trusted certificate chain to a trusted root CA. Common causes: (1) The signing certificate's root CA is not in Acrobat's trusted certificate store or the system's certificate store. (2) A certificate in the chain is missing — the intermediate CA certificate was not embedded in the signature. (3) The signature is self-signed (no chain to a trusted CA). (4) Acrobat could not reach the internet to download missing certificates or check revocation. To fix: ensure the full certificate chain (end-entity + all intermediate CAs) is embedded in the signature, and verify the root CA is trusted by Acrobat's Trusted Identities or the system certificate store. Enterprise deployments typically distribute trusted root CAs via certificate management tools.

How do I add LTV to an existing signed PDF?

Adding LTV to an existing signed PDF is an incremental update operation: new DSS dictionary objects containing certificates, OCSP responses, and CRLs are appended to the file without modifying the original signed byte range. The signed content is preserved intact; only DSS data is added. This is a legitimate operation explicitly supported by the PDF signature model. Tools that support LTV addition include: pyHanko (Python, open-source) via its stamp workflow; iText 7 (Java/C#, AGPL/commercial) via LtvVerification; Adobe Acrobat Pro (GUI: the signature panel will offer to add LTV information after validation). After adding LTV, a final document timestamp (PAdES-LTA) should be added to seal the DSS data.

What happens to PDF signatures when a certificate expires?

Certificate expiry and certificate revocation are different events with different implications. When a certificate expires (its notAfter date passes), the certificate is no longer valid for new signatures — but existing signatures made while the certificate was valid remain valid, provided revocation information was embedded at signing time. The validity period of a signature is determined by the timestamp at signing time, not the certificate's expiry. Without an embedded timestamp, a validator can only confirm the signature was made before the certificate expired — not when exactly. This is why timestamps are essential for archival signatures: they anchor the signature validity to a specific moment within the certificate's valid period.

Try it yourself

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

Sign PDF Edit PDF Open editor