Digital Signature Internals in PDF

A digital signature on a PDF is more than a scribbled image. It's a cryptographic operation that proves who signed, when, and that the document hasn't been altered since. Underneath sit certificates, hashes, byte ranges, and a precise place in the PDF object structure. This guide goes deeper than digital signatures vs electronic signatures into the actual mechanics.

What a digital signature is

Cryptographically:

The signer has a certificate issued by a trusted authority, containing their public key.
To sign, they compute a hash of the document.
They sign the hash with their private key, producing a signature.
The signature plus certificate is embedded in the PDF.

To verify:

Recompute the hash of the document.
Use the certificate's public key to verify the signature against the hash.
Check the certificate chains to a trusted root.

If the hash matches, the document hasn't changed since signing. If the certificate is valid, the signer is who they claim.

The signature dictionary

In the PDF, a signature is an object:

10 0 obj
<<
  /Type /Sig
  /Filter /Adobe.PPKLite
  /SubFilter /adbe.pkcs7.detached
  /ByteRange [0 12345 13000 50000]
  /Contents <hex-encoded-signature>
  /Cert <hex-encoded-certificate>
  /Name (John Smith)
  /Reason (Approval)
  /Location (San Francisco)
  /M (D:20260517120000-08'00')
>>
endobj

Key fields:

/Filter: the signature handler. Adobe.PPKLite is most common.
/SubFilter: the signature format. adbe.pkcs7.detached is standard.
/ByteRange: ranges of the file that were hashed (excludes the signature itself).
/Contents: the signature bytes (hex-encoded, fixed length, zero-padded).
/M: the signing time.

The ByteRange

The trickiest part. The signature covers most of the file but not the signature object itself.

[0 12345 13000 50000] means:

Bytes 0 to 12344 (length 12345) are included.
Bytes 13000 to 50000 (length 37001) are included.
Bytes 12345 to 12999 are skipped (this is where the signature lives).

The PDF tool computes the hash over the included bytes, signs it, and writes the signature into the skipped range. Verification recomputes the hash over the same byte ranges and verifies the signature.

If the file is modified after signing, the hash changes; the signature no longer verifies.

Why ByteRange-based?

A PDF signature object must be inside the PDF (so it's stored alongside the document). The signature itself is part of the file. The signature cannot cover the bytes that contain it (chicken-and-egg). The ByteRange approach signs everything except the signature.

Signature handlers

The signature handler controls the format:

Adobe.PPKLite: Adobe's default. Supports PKCS#7 detached signatures.
Adobe.PPKMS: Microsoft Crypto API integration.
Entrust.PPKEF: legacy Entrust handler.

SubFilter distinguishes formats:

adbe.pkcs7.detached: PKCS#7 with detached data; the most common.
adbe.pkcs7.sha1: older variant with SHA-1 hash. Deprecated; SHA-1 broken.
adbe.x509.rsa_sha1: older raw signature without PKCS#7 wrapping.
ETSI.CAdES.detached: European Telecommunications Standards Institute CAdES format. Used in eIDAS-conformant signatures.

For new signatures in 2026, prefer adbe.pkcs7.detached with SHA-256 or stronger, or ETSI.CAdES for European compliance.

Certificates

The signer's certificate is included in the signature:

Subject: who the certificate identifies.
Issuer: which CA issued it.
Public key: used to verify signatures.
Validity period: not-before, not-after dates.
Extensions: usage flags, policy identifiers.

The certificate chains up to a root CA. The verifier needs to trust the root.

Common roots:

Adobe Approved Trust List (AATL): Adobe's list of trusted signing CAs. Acrobat trusts AATL by default.
EU Trusted Lists (EUTL): for eIDAS-qualified signatures.
System trust stores: Windows/macOS/Linux CA stores.

For self-signed certificates (common in test environments), recipients must explicitly trust the certificate.

PKCS#7 and CMS

The signature wraps the actual cryptographic signature in PKCS#7 (also known as CMS, Cryptographic Message Syntax). This includes:

The signed hash.
The signing algorithm.
The signer's certificate and chain.
Optionally: timestamps, revocation information.

PKCS#7/CMS is a standardized format used across many crypto applications, not just PDFs.

Timestamps

A signature includes the signer's claimed signing time. This time is asserted by the signer and can be backdated. For trustworthy timestamps:

Time Stamping Authority (TSA): a trusted third party that signs a timestamp request.
RFC 3161: the standard for timestamp protocol.
PDF timestamp signatures: a separate signature type that adds a TSA timestamp.

A properly timestamped signature proves "the document existed before this trusted timestamp."

For long-term validation, timestamps matter: certificates eventually expire; a timestamp proves the signature was valid at signing time.

Long-Term Validation (LTV)

Standard signatures have a problem: the signer's certificate eventually expires or gets revoked. Verifying years later may fail.

LTV signatures embed:

Certificate chain (the signer's cert plus all intermediates plus root).
Revocation info (CRL or OCSP responses) at signing time.
Trusted timestamps.

A future verifier can check the signature without needing live access to CAs and CRL servers.

For documents that need to be verifiable decades later (legal contracts, regulatory filings), LTV is essential.

Signature types in PDF

Three signature types defined in the PDF spec:

Approval signatures: most common. Each adds a signature to the document.
Certification signatures (also called "MDP" for Modification Detection and Prevention): only one per document; restricts subsequent changes.
Usage rights signatures: from Adobe, enable specific reader features.

Certification signatures specify allowed changes:

No changes allowed.
Form fill-in only.
Form fill-in and annotations.

If a recipient makes a change beyond what's permitted, the signature shows as invalidated.

Multiple signatures

A PDF can have multiple approval signatures. Each is added as an incremental update to the file (see PDF incremental updates explained).

The signing process:

The PDF has signature 1 covering bytes [0..N].
Signer 2 adds an incremental update with signature 2 covering bytes [0..M] where M > N.
Signer 2's signature covers signer 1's signature plus the new content.

Verification: each signature is checked against the bytes it claims to cover.

Signature visualization

A signature has a visible appearance (the signed-by box, signature image, etc.) and a logical signature (the cryptographic data).

The visible appearance lives in a Widget annotation; the cryptographic data is in the Sig object. They're linked but separate.

For accessibility and clarity, the visible appearance typically shows: signer name, date, reason, signed-by-logo or scribbled signature image.

Signing tools

For creating digital signatures:

Adobe Acrobat / Reader: built-in signing with a certificate.
DocuSign, Adobe Sign, HelloSign: cloud signing services.
Open source: pyHanko (Python), iText (Java/.NET), OpenPDF, jsign.
Hardware: smart cards, hardware security modules (HSM), eIDs (Estonia, Belgium, Italy, etc.).

For organizations: certificates from a CA (DigiCert, GlobalSign, Sectigo, IdenTrust); or self-signed for internal use.

Verification

For verifying signatures:

Acrobat / Reader: built-in. Shows signature panel with details.
Adobe Verifier (online): for quick checks.
Open source: pyHanko, iText verify modes.
Command line: pdfsig (poppler), mutool.

When verification fails, common causes:

Document modified after signing.
Certificate expired and no LTV info.
Certificate not trusted by the verifier.
Algorithm mismatch (very old SHA-1 signatures).

Legal frameworks

Different jurisdictions have different requirements:

eIDAS (EU): Simple, Advanced, Qualified electronic signatures. Qualified signatures use specific hardware-secured certificates from qualified TSPs and have legal parity with handwritten signatures.
ESIGN / UETA (US): more permissive; most e-signatures are legally valid.
PIPEDA (Canada), others: similar to ESIGN.

For more, see e-signature laws around the world and is it legal to sign documents electronically.

Common gotchas

Document modified after signing. Even saving the file in some tools modifies it, invalidating the signature. Use only signing-aware tools.

Self-signed certificates not trusted. Internal use is fine; external sharing requires recipients to manually trust the certificate.

Expired certificate without LTV. Years later, the signature can't be validated. Use LTV for long-lived documents.

Wrong hash algorithm. SHA-1 is deprecated; use SHA-256 or stronger.

Time desynchronization. Signer's clock is wrong; signing time is misleading. Use TSA for trustworthy time.

Multiple-signature mistakes. Adding a non-incremental save after signing breaks all signatures.

Practical recipe

For a robust signing workflow:

Use a trusted CA for external-facing signatures.
SHA-256 or stronger hash algorithm.
PKCS#7 detached subfilter.
LTV-enabled for long-lived documents.
TSA timestamp for trustworthy time.
Certification signature for documents you want to lock down.
Verify in multiple tools before relying.

For browser-based PDF preparation before formal digital signing (combining, filling forms, redacting), Docento.app handles the local steps. Digital signature application typically requires a desktop tool or a cloud signing service.

Takeaway

Digital signatures in PDFs are a serious cryptographic mechanism, not just a graphic. Understanding the internals (ByteRange, certificates, PKCS#7, timestamps, LTV) is what separates working signing pipelines from broken ones. For high-stakes signing (contracts, regulatory filings), invest in the right CA, the right algorithms, and LTV-enabled timestamps. See also digital signatures vs electronic signatures, e-signature laws around the world, and PDF internals: objects and streams.