Security 10 min read 21 October 2026

PDF Certificate Signing: X.509, Trust Chains, and Building a Signing Workflow

Certificate-based PDF signing uses X.509 public-key infrastructure to bind a document to a verified identity. This guide covers certificate types (self-signed vs CA-issued), trust chain validation, timestamp authorities, long-term validation (LTV), and how to set up a signing workflow using Adobe Acrobat, pyHanko, and iText.

Certificate-based PDF signing is the gold standard for document authentication: it binds a document to a verified identity using public-key cryptography, produces a tamper-evident seal, and can be verified by any PDF viewer without contacting the signer. Unlike a graphical signature image — which proves nothing — a certificate-based signature proves that a specific private key (associated with a verified identity) was used to sign this exact byte sequence. Understanding how this works demystifies both the impressive capabilities and the specific failure modes. A signature that shows "Valid" in Acrobat may still not be legally binding. A signature that shows "Signature validity unknown" may be entirely technically sound. The difference lies in certificate trust chains, timestamp authorities, and long-term validation data — all of which this guide explains. Whether you are verifying signatures you receive, building a signing workflow for your organisation, or evaluating signing service providers, this guide covers the complete technical picture.

X.509 certificates and the trust chain

A PDF digital signature uses an X.509 certificate to identify the signer. An X.509 certificate is a file containing: the subject's public key; the subject's identity (name, organisation, email); the issuer's identity (the certificate authority that verified the subject's identity); the validity period; and the issuer's digital signature over all of the above. Trust chain validation — When verifying a PDF signature, the verifier does not just check the signer's certificate. It checks the entire chain of certificates from the signer's certificate up through intermediate CAs (Certificate Authorities) to a root CA whose certificate is trusted by the system's trust store. The chain works like this: 1. Signer's certificate: "I am Alice, verified by GlobalSign CA" 2. GlobalSign Intermediate CA certificate: "GlobalSign Intermediate was issued by GlobalSign Root" 3. GlobalSign Root CA: trusted by the operating system (in Windows Certificate Store, macOS Keychain, Firefox/Chrome trust store) If any link in the chain is broken (expired, revoked, not trusted), the signature shows as invalid even if the cryptographic operations are perfectly valid. Self-signed certificates — A certificate signed by its own private key (not by a CA) has no chain — the verifier must explicitly choose to trust it. Self-signed certificates are appropriate for internal document workflows where the receiving parties can be told to import the certificate into their trust store. They produce "Signature validity unknown" in Acrobat unless the recipient has explicitly trusted the certificate. Certificate revocation — If a certificate is compromised or withdrawn, the CA publishes it on a Certificate Revocation List (CRL) or makes it available via OCSP (Online Certificate Status Protocol). Signature verification should check revocation status — a valid signature from a subsequently revoked certificate should be treated as potentially compromised. See PDF Digital Signatures for the full verification workflow.

Timestamp authorities and long-term validation (LTV)

A PDF signature without a timestamp proves the document was signed — but not when. If the signer's certificate expires or is revoked after signing, a timestampless signature cannot be reliably verified later. The timestamp solves this: RFC 3161 timestamps — A timestamp token from a trusted Timestamp Authority (TSA) is a signed assertion that a specific document hash existed at a specific time. The TSA's signature is independent of the signer's — even if the signer's certificate is later revoked, the timestamp proves that the document existed and was signed before the revocation. PAdES-T signatures — The PAdES-T (PDF Advanced Electronic Signatures with timestamp) profile embeds an RFC 3161 timestamp in the PDF signature. This is the minimum recommended configuration for any signature that needs to be verified more than a few months after signing. Long-Term Validation (LTV) — For signatures that must be verifiable years or decades later (contracts, archives, legal records), the complete validation chain (certificate chain, revocation information for all certificates, timestamps) must be embedded in the PDF. This is the PAdES-LT/LTA level. Without embedded validation data, a signature that was valid at signing time may become unverifiable when the CA's OCSP responder is decommissioned, CRL distribution points are taken offline, or root CA certificates are removed from trust stores. Enabling LTV in practice — Acrobat Pro: sign with a timestamp and then use Document > Signatures > Document Security > Enable Long-Term Validation. iText and pyHanko both support LTV addition programmatically. LTV increases file size because it embeds the full certificate chain and revocation data, but this is acceptable for the archival value.

Building a signing workflow

Choosing a signing tool: Adobe Acrobat Pro — GUI-based, certificate management integrated with Windows Certificate Store / macOS Keychain, supports timestamp servers, LTV, PAdES profiles, certification signatures (/DocMDP), and approval signatures. Best for individual or small-team workflows. pyHanko — Open-source Python library for PDF signing. Supports PAdES-B/T/LT/LTA, PKCS#12 certificate loading, hardware tokens via PKCS#11, and batch signing. Excellent for automated signing workflows. Available on GitHub. iText (Java/.NET) — Commercial PDF library with comprehensive signing support. Widely used in enterprise Java applications for high-volume document signing workflows. iText Sign module handles PAdES, LTV, and multiple signature appearances. Cloud signing services — DocuSign, Adobe Sign, and GlobalSign Digital Signing Service provide API-accessible signing with managed certificate infrastructure. These eliminate the need to manage private keys and certificates internally. They are appropriate for high-volume signing, multi-party signing workflows, and e-signature compliance requirements. Hardware security modules (HSMs) — For regulated industries (finance, healthcare, government), private signing keys must be stored in hardware security modules rather than software key stores. HSMs are tamper-resistant hardware devices that perform signing operations without exposing the private key. Cloud HSM services (AWS CloudHSM, Azure Dedicated HSM) provide HSM capability without on-premises hardware.

Frequently asked questions

What is the difference between a certification signature and an approval signature in PDF?

A certification signature (created with /DocMDP — Document Modification Detection and Prevention) is a special "first signature" that specifies what changes are permitted after the document is certified. The author certifies the document's original state and declares: no changes permitted; form fields may be filled; or annotations and form fields may be added. Any subsequent change beyond the declared permission level invalidates the certification. An approval signature is a standard signature added to a document (possibly after certification) that approves the document's content at a specific point in time. Multiple approval signatories can sign the same document sequentially. The signature field panel in Acrobat shows each signer separately. A certification signature appears first and with a special blue ribbon icon in Acrobat's signature panel.

Why does a PDF signature show "Signature validity unknown" even though the document hasn't been changed?

"Signature validity unknown" typically means the verifier cannot establish trust for the signer's certificate — not that the document has been modified. Common causes: (1) Self-signed certificate — the verifier hasn't been told to trust it; import the certificate into your trust store. (2) Intermediate CA certificate not included in the signature — the verifier can't complete the trust chain; the signer should include the full chain in the signature. (3) Certificate from an authority not in the verifier's trust store — enterprise or national trust anchors not in the default Adobe/OS trust store. (4) Revocation checking failed — OCSP/CRL servers unreachable; the verifier defaults to "unknown" when it can't confirm revocation status. The blue ribbon in Acrobat means "trusted certificate"; the yellow triangle means "unknown trust"; the red X means "invalid" (document modified or certificate cryptographically broken).

How do I add a visual signature appearance to a PDF certificate signature?

A certificate-based PDF signature is primarily a cryptographic operation — the visual appearance is optional and separate from the signature validity. The visual appearance is an /AP (appearance stream) on the signature widget annotation. In Acrobat Pro, you can define a signature appearance including a graphical image, name, date, and reason. In pyHanko, use StampStyle or SimpleSigner with an appearance configuration. In iText, use PdfSignatureAppearance to define font, image, and layout. Importantly: the visual appearance is cosmetic. A signature that is visually impressive but uses a self-signed certificate untrusted by the recipient is no more legally binding than no signature at all. Conversely, an invisible signature with a properly validated certificate from a trusted CA is cryptographically and legally valid without any visual element.

Try it yourself

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

Sign PDF Protect PDF Edit PDF Open editor