PDF signature verification: what developers need to know

"Digitally signed" on a PDF means different things to different people. In a legal context it often means an image of a signature was inserted. In a cryptographic context — which is what actually matters for tamper detection — it means the document's contents were hashed and that hash was signed with a private key whose corresponding certificate traces back to a trusted authority. Those two things can coexist in the same document, but only one of them provides any security guarantees.

What a cryptographic PDF signature actually is

A PDF digital signature uses the same technology as HTTPS certificates and code signing: asymmetric cryptography. The signer has a private key; the signature is a hash of the signed content encrypted with that private key. Anyone with the corresponding public key (embedded in the signer's certificate) can:

1. Decrypt the signature to recover the hash.
2. Independently compute the hash of the document content.
3. Compare the two. If they match, the document hasn't been modified since signing; if they don't, it has.

The certificate also identifies who signed (name, organization) and is itself signed by a Certificate Authority (CA), creating a chain of trust up to a root CA your system trusts — the same trust chain as HTTPS.

Signature coverage: what's actually signed

This is the most common source of confusion. A PDF signature only covers the byte range it declares — the bytes in the document that were present at the time of signing, explicitly specified in the signature's /ByteRange field. This is important because:

• Incremental updates: PDFs can be modified by appending new content to the end of the file without altering prior bytes. A valid signature from before an incremental update is still cryptographically valid — it was valid for the content that existed when it was signed. Adobe and other verifiers distinguish between "signature is valid" and "document has been modified after signing."
• Multiple signatures: a PDF can have multiple signatures, each covering a different byte range. The last signer typically covers the whole document up to their signature; earlier signers may have signed less.
• Unsigned content: form fields filled out after the signature was applied are not covered by that signature. A document can show as "signed and valid" while containing form data that was never verified.

Carefully-built PDF validation shows you the byte range diagram — exactly which bytes each signature covers and whether there are any unsigned bytes appended after the last signature.

Certificate chain and trust

The signer's certificate must be issued by a CA your system trusts. If the signing certificate is self-signed (the signer is their own CA), the signature is cryptographically valid but the identity is unverifiable — anyone could create a self-signed certificate claiming to be anyone else.

The trust anchor matters enormously for business use cases:

• Adobe Approved Trust List (AATL): the set of CAs Adobe trusts by default. A signature from an AATL-trusted certificate shows a green checkmark in Acrobat. Your application may or may not trust the same roots.
• European Trust Lists (EU QTSP): qualified trust service providers under eIDAS regulation — the legal framework for electronic signatures in the EU. These have specific legal weight in EU member states.
• Private PKI: organizations often sign internal PDFs with certificates issued by their own internal CA. These are cryptographically sound but won't be trusted by default in external tools.

Timestamp signatures and long-term validity

A signature proves the document was unchanged from the moment it was signed. But what was the moment of signing? The signer's system clock is self-reported and untrustworthy. This is solved by a trusted timestamp, issued by a Time Stamping Authority (TSA): an independent third party that attests "this hash was presented to us at this time," signed with the TSA's own certificate.

Timestamps also address the key revocation problem: if a signer's certificate is later revoked (compromised, expired), a timestamped signature that predates the revocation is still considered valid — the signature was made with a valid certificate, and the timestamp proves when. Without a timestamp, verifying a signature after the signing certificate expires or is revoked becomes ambiguous.

Long-term validation (LTV) embeds the full certificate chain, OCSP responses, and CRL data into the PDF at signing time, so the document remains verifiable even after the signing service or TSA is no longer available.

What to verify programmatically

If you're building PDF signature verification into an application, the checklist is:

1. Parse the /ByteRange and verify the hash — confirm the declared bytes match the computed hash.
2. Verify the signature against the certificate's public key.
3. Validate the certificate chain to a trust anchor you control.
4. Check revocation — OCSP or CRL for each certificate in the chain, as of the signing time.
5. Verify the timestamp (if present) and confirm the signing certificate was valid at that time.
6. Check for post-signature modifications — any bytes appended after the last signature's byte range.

Libraries like pdf-lib, iText, and Apache PDFBox expose different levels of this; none of them are one-liners, because the full verification is genuinely multi-step.

Certificate transparency

If the signing certificate was issued by a publicly-trusted CA, it may appear in the Certificate Transparency log — a public append-only log of all certificates issued by participating CAs. Our Certificate Transparency Log Lookup searches those logs by domain, letting you see what certificates have been issued under any domain — useful for auditing what signing certificates exist for your organization.