How to Verify a Digitally Signed PDF Document

Table of Contents

1. Electronic signatures and digital signatures are not the same
2. The legal frameworks in brief
3. X.509 certificates and the PKI behind them
4. How a PDF digital signature is built
5. What verification actually checks
6. Certificate chains and trust
7. Revocation: CRL and OCSP
8. Verifying in Adobe Acrobat
9. Verifying in browsers and other viewers
10. Verifying from the command line
11. Reading the result: valid, unknown and invalid
12. Common verification failures
13. A verification procedure for buyers and reviewers

Electronic signatures and digital signatures are not the same

The phrase "signed PDF" hides two distinct things, and confusing them is the most common error in signature review.

An electronic signature is an electronic indication of consent. In the European Union's eIDAS Regulation, it is defined broadly as data in electronic form attached to or logically associated with other data, which the signatory uses to sign. A typed name, an image of a handwritten signature, or a click on "I agree" in a platform can all be electronic signatures. Platforms such as DocuSign and HelloSign (now part of Dropbox Sign) produce electronic signatures, typically with an audit trail that records the signer's email address, IP address, timestamps and the actions taken. That audit trail can be persuasive evidence, and in many jurisdictions it is legally effective, but it is not, by itself, a cryptographic guarantee about the document's bytes.

A digital signature is a cryptographic construction. The signer's private key is used to sign a value derived from the document, usually a cryptographic hash, and the signature is stored in the file. Anyone who has the signer's certificate, which contains the corresponding public key, can check whether the signature matches the document's current bytes. If a single byte of the signed portion has changed, the check fails. The signature also binds the signature to a certificate, which in turn is issued by a certification authority that vouches for the identity of the holder under specified conditions.

In practice, many platforms produce both. A document may be signed through a platform that applies a visible signature image and an audit certificate, and also carries a digital signature for integrity. When you verify, you need to know which layer you are relying on. A visual signature is not evidence of integrity. A digital signature is evidence of integrity and of a certificate's involvement, but its value depends on the trust you place in the certificate.

The legal frameworks in brief

Legal treatment of signatures differs by jurisdiction, and this article is not legal advice. The following points are the baseline most readers need.

In the European Union, Regulation (EU) No 910/2014, known as eIDAS, defines three levels of electronic signature: simple, advanced and qualified. An advanced electronic signature is uniquely linked to the signatory, capable of identifying the signatory, created under the signatory's sole control, and linked to the signed data so that a later change is detectable. A qualified electronic signature is an advanced signature created by a qualified signature creation device and based on a qualified certificate. A qualified signature has the legal effect of a handwritten signature across the Union. Amendments adopted in 2024 introduce a framework for the European Digital Identity Wallet and update the trust services provisions, and you should check the current text for any specific procurement requirement.

In the United States, the federal ESIGN Act (15 U.S.C. 7001) provides that a signature may not be denied legal effect solely because it is electronic, and most states have adopted the Uniform Electronic Transactions Act. Those laws focus on the intent to sign and the record of the process, not on a particular cryptographic method. The US framework therefore accepts a wider range of signatures than eIDAS does, and the evidentiary value depends on the circumstances.

For PDF specifically, the standards that define the format and its digital signatures are ISO 32000-2 for the PDF structure and ETSI standards for the advanced signature profiles known as PAdES. ETSI EN 319 142-1 specifies the baseline profiles for PAdES signatures. These standards define how the signature is stored, which algorithms are expected, and what a validator must check.

X.509 certificates and the PKI behind them

A digital signature is only as meaningful as the identity it is attached to, and that identity is carried in an X.509 certificate. The format is defined in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List profile.

A certificate binds a public key to a subject name and is signed by an issuer. It contains the subject and issuer distinguished names, a validity period, the subject's public key, the signature algorithm, a serial number and a set of extensions. Several extensions matter for PDF signatures. The Key Usage extension states what the key may be used for, including digital signature and non-repudiation. The Extended Key Usage extension can specify purposes such as document signing, email protection, or time stamping. The Basic Constraints extension indicates whether the certificate belongs to a certification authority. The CRL Distribution Points extension tells a validator where to fetch a certificate revocation list. The Authority Information Access extension tells it where to find the issuer's certificate and an online responder.

Certificates form a hierarchy. A root certification authority issues certificates to intermediate authorities, which in turn issue end-entity certificates to signers. The root's certificate is self-signed and is trusted only because it is placed in a trust store. Every validator maintains a set of trusted roots, and a signature validates only if its certificate chain leads to one of them.

This is the Public Key Infrastructure, PKI, and its trust model is the central fact of digital signature verification. A signature can be mathematically correct and still untrustworthy, if the certificate was issued by an unknown authority, if it is self-signed, or if it was revoked. Verification is the process of checking mathematics and trust together.

Two lists of trusted roots are especially relevant for PDF users. The Adobe Approved Trust List is maintained by Adobe and includes certification authorities whose certificates Acrobat trusts by default. The European Union Trusted List, which is published by member states under eIDAS, lists qualified trust service providers. Your organization may also maintain its own trust store for internal certificates.

How a PDF digital signature is built

A PDF digital signature is stored in a signature dictionary, which is referenced from a form field of type signature. The signature dictionary contains the filter and subfilter that name the signature format, the signing time if present, the signer's name, the reason and location if provided, and two critical entries.

The first is /ByteRange, an array of four integers that specify two byte ranges of the file. These ranges cover the whole file except for the signature's own /Contents value, which is a hexadecimal string that holds the signature container. The ranges are chosen so that the signature does not cover itself.

The second is /Contents, which holds a PKCS #7 or CMS signed-data structure, defined in RFC 5652. The container includes the signer's certificate, optionally the rest of the chain, the signed attributes and the signature value. The signed attributes include the message digest, which is the hash of the bytes described by the byte ranges, and usually the signing time and the content type. The signature value is computed over the signed attributes using the signer's private key. For RSA-based signatures, the padding and encoding are defined in RFC 8017, the PKCS #1 standard.

Verification reverses this. A validator reads the byte ranges, computes the hash of those bytes, compares it with the message digest in the signed attributes, and then verifies the signature value over the signed attributes with the public key in the signer's certificate. If the hash matches and the signature verifies, the bytes covered by the byte ranges have not changed since signing, and the signature was made by the holder of the corresponding private key.

Two further points matter in practice. First, PDF supports incremental updates, which append changes to the end of the file. A change made after signing does not change the bytes covered by the byte ranges, so the original signature still validates, but the appended changes are not covered by it. Acrobat reports this as a modification after signing. Second, the document may contain a certification signature, under the DocMDP mechanism defined in ISO 32000-2. Certification signatures specify which changes are permitted after signing, such as form filling or the addition of annotations. A change that exceeds the permitted set invalidates the certification.

The signing time that appears in a signature is the time the signer's software claims, unless it is backed by a trusted timestamp. A timestamp is issued by a time-stamping authority under RFC 3161, and it provides evidence that the signature existed at a given time. Without a timestamp, the signing time is a claim by the signer's machine.

What verification actually checks

A complete verification performs several checks. Each one answers a different question.

The integrity check asks whether the signed bytes are unchanged since signing. It compares the message digest with the hash of the byte ranges and verifies the signature value with the signer's public key. A failure here means the signed content has been altered, or the signature is corrupt.

The certificate validity check asks whether the signer's certificate was valid when the signature was made. It compares the signing time, or the timestamp time if present, with the certificate's validity period. An expired certificate can still produce a valid signature if the signature was made within its validity period and is timestamped, and this is a common source of confusion.

The trust check asks whether the certificate chain leads to a root that the validator trusts. The validator builds the path from the signer's certificate to a trusted root, using the intermediate certificates in the signature and any available from the authority information access locations. If the path cannot be built, or it leads to an untrusted root, the signature is cryptographically valid but its identity is unknown.

The revocation check asks whether any certificate in the path was revoked, and whether the revocation status was current at the time of signing or at the time of verification. Revocation is covered in the next section.

The policy check asks whether the certificate is suitable for the purpose it was used for. A certificate issued for email encryption may not be appropriate for document signing, depending on its Extended Key Usage. Some validators check this, and some do not.

The algorithm check asks whether the signature uses algorithms that the validator considers acceptable. SHA-1 is deprecated for signatures, and RSA keys below 2048 bits are not acceptable under current guidance. NIST FIPS 186-5 specifies the Digital Signature Standard, and NIST SP 800-131A Rev. 2 describes the transition away from weaker algorithms and short keys. A signature that uses a deprecated algorithm may validate in an old tool but be rejected by a current one.

A verification report that says "valid" should mean that the integrity check and the trust check both passed, and that revocation was checked and found clear. Read the detail. A report that says the signature is cryptographically intact, but the identity is unknown, has passed only the first check.

Certificate chains and trust

The trust check is where most practical verification problems arise, so it deserves attention.

A certificate chain is the sequence from the end-entity signer's certificate up through any intermediate certificates to the root. Validation requires that each certificate in the chain was issued by the next, that each signature in the chain verifies, that each certificate is within its validity period, that each issuer is authorized to issue certificates by the Basic Constraints extension, and that the chain ends in a trusted root. RFC 5280 section 6 specifies the path validation procedure.

A signature can carry only the end-entity certificate, and the validator must find the intermediates elsewhere. If the intermediates are not available, the chain cannot be built, and the signature is reported as having unknown validity even though its integrity is intact. This is common when a signing platform does not embed the chain, or when a validator cannot reach the authority information access location.

A self-signed certificate is the simplest untrusted case. It is its own issuer, and it is trusted only if the validator has been told to trust that specific certificate. A self-signed certificate created inside an organization can be useful for internal workflows, but it proves nothing to an outside recipient unless that recipient has added it to their trust store.

Trust is a decision, not a fact. Adobe's default trust store includes the roots on the Adobe Approved Trust List. A certificate from a root outside that list will not be trusted by default, even if it is a legitimate commercial authority. A recipient who wants to verify such a signature must either add the root to their trust store, check the signer's identity through another channel, or accept that the identity is unverified. Document the decision.

Revocation: CRL and OCSP

A certificate can be valid by its dates and still be revoked. Revocation happens when a private key is compromised, when an employee leaves, when the subject's details change, or when the issuing authority ceases operations. A validator must check revocation at the relevant time, or the trust check is incomplete.

There are two main mechanisms. A certificate revocation list, or CRL, is a signed list published by the issuing authority at intervals. It names the serial numbers of revoked certificates. RFC 5280 defines the CRL format. CRLs have a next-update time, and a validator must fetch a sufficiently recent list. Some authorities publish delta CRLs that carry only changes since a base list. The limitation of CRLs is their freshness: a revocation that occurs after the list was published will not appear until the next publication.

Online Certificate Status Protocol, or OCSP, is a request-response mechanism defined in RFC 6960. The validator sends a query for a specific certificate to the authority's responder, and the responder returns a signed statement of good, revoked or unknown. OCSP responses are more current than CRLs, but they depend on the responder being reachable at verification time. An offline validator may be unable to check the status, and its report will reflect that.

For long-term validity, PAdES defines methods for embedding revocation information and timestamps into the document, so that the signature can be verified years later even when the responder is no longer available. The Document Security Store, or DSS, is the PDF structure that carries this material. A document with a DSS and a document timestamp is said to have long-term validation. Without these, a signature may validate today and fail tomorrow when the responder's records are gone or the certificate has expired and cannot be checked against a status at signing time.

When a validator cannot determine revocation status, it may report the signature as having unknown validity. That is a correct outcome. It means the validator cannot confirm that the certificate was not revoked, and the recipient should decide whether to accept the risk.

Verifying in Adobe Acrobat

Acrobat is the reference validator for PDF signatures, and its trust decisions are visible.

Open the document and open the Signatures panel, or click the signature field. Acrobat displays a status summary at the top of the panel. A message that says the signatures are valid and that the document has not been modified indicates that the integrity and trust checks passed, subject to revocation checks that completed. Click each signature to see its details: the signer's name, the signing time, the certificate issuer and the validity status.

To inspect the certificate chain, open the signature's properties and view the certificate details. Acrobat shows the chain from signer to root, and it indicates whether each certificate is trusted. If the root is not on the trusted list, you can add it through the Trust Manager, under the preferences for signatures, but do so only after you have verified the root's identity through a reliable channel. Adding roots widely is a serious change to your trust decisions.

Pay attention to messages about modifications after signing. Acrobat reports when the document has changed since the signature was applied. Decide whether the changes are acceptable for the purpose, and check whether a certification signature restricted them.

Acrobat's verification depends on the trust store and on network access for revocation. Verify on a machine configured with your organization's trust policy, and record the result.

Verifying in browsers and other viewers

Browser PDF viewers and many lightweight readers display signature fields and sometimes show that a signature is present. Their validation of signatures is typically less complete than Acrobat's. Some do not perform full chain building or revocation checking, and some show a signature without any cryptographic verification at all.

Do not treat a browser's display of a signature as verification. If a document is important enough to need a signature, verify it in a tool designed for the purpose, such as Acrobat, the open-source command-line tools described below, or a validation service operated by a trusted party. Treat a browser's view of a signature as a preview.

Apple Preview and other macOS viewers may show signature information, but their depth of validation varies by version. Confirm the behaviour on your version before relying on it.

Verifying from the command line

The command line gives the most transparent view of what a signature contains. The Poppler utilities include pdfsig, which checks PDF signatures and reports their validity. It is a useful second opinion and a good tool for automated checks.

pdfsig signed-contract.pdf

The output lists each signature, its signer, its signing time if present, and its validation result. Read the validation line carefully, because pdfsig reports the integrity and certificate checks it performs, and the trust of the root depends on the trust store the tool uses. Compare the output with Acrobat's result for the same file.

For a deeper look, extract the signature container and examine it with OpenSSL. First, identify the byte ranges and the hex-encoded /Contents value in the file. A short script can read the /ByteRange array, extract the bytes covered by the signature, and write the /Contents value to a file as binary. Then use OpenSSL to parse the CMS structure:

openssl cms -cmsout -inform DER -in signature.der -print

The output shows the signer's certificate, the signed attributes and the digest algorithm. Compare the message digest with the hash of the byte ranges computed independently. Keep scripts that handle untrusted documents in their own directory, and run parsing tools on copies of the file, not on originals.

For programmatic validation and signing, pyHanko is an open-source Python library for PDF signatures. The European Commission also publishes the Digital Signature Service library, DSS, at its GitHub repository, which implements the validation of PAdES and related signature forms in Java. Use these libraries when you need to verify many documents consistently and record the results, but verify the library's behaviour against Acrobat for a sample of documents first.

Reading the result: valid, unknown and invalid

Verification tools use different wording, but the outcomes fall into a small set of categories. Understand what each one means before you act on it.

A valid signature means that the integrity check passed, the chain was built to a trusted root, and revocation was checked and found clear, at least to the extent the validator could check it. This is the outcome you want when identity matters.

A valid but untrusted or unknown identity signature means the bytes are intact and the signature matches the certificate, but the certificate does not chain to a root the validator trusts. The signature proves that the document has not changed since the holder of that certificate signed it. It does not prove who that holder is, in a way the validator accepts.

A validity unknown signature usually means that the validator could not complete a check, most often revocation or chain building. The status is not necessarily a sign of forgery. It is a sign that the validator cannot confirm the status, so the decision to accept the signature is a risk judgment.

An invalid signature means that a check failed in a way that indicates a problem. The document may have been altered after signing, the signature may be corrupt, or the certificate may have been revoked or may not match the signature. Do not rely on an invalid signature. Investigate it.

A signed and modified outcome means the integrity of the signed content is intact, but the document has been changed after signing through an incremental update. Whether that is acceptable depends on the change and on any certification restrictions.

Common verification failures

The following failures appear most often in procurement, legal and HR workflows. Each has a predictable cause.

Failure 1: The signature is a visual image, not a digital signature. Many platforms apply a visible signature stamp and an audit page, but no cryptographic signature in the PDF. The verifier finds no signature field or finds one with no valid signature. Ask the sender which signing method was used and whether a digital signature was applied.

Failure 2: The certificate is self-signed or from an unknown root. The integrity check passes, but the trust check fails. The recipient must decide whether to trust the root, and should verify the signer's identity through another channel.

Failure 3: The chain is incomplete. The signature carries the end-entity certificate but not the intermediates, and the validator cannot reach the issuer. The result is unknown validity. Ask the sender to re-sign with the full chain embedded, or obtain the intermediates from the issuer's published location.

Failure 4: Revocation cannot be checked. The validator is offline, the OCSP responder is unreachable, or the CRL is stale. The result is unknown revocation status. Retry from a connected machine, and consider whether the document is time-sensitive.

Failure 5: The certificate has expired, and there is no timestamp. A signature made after the certificate's validity period is not necessarily valid, and a signature without a trusted timestamp does not prove the signing time. The validator may report the signature as invalid or as having a problem with the certificate's validity. A timestamped signature made within the validity period remains valid after the certificate expires, and that is the reason timestamps matter.

Failure 6: The document was modified after signing. An incremental update, such as a comment, a form change or a re-save with a new object, appears after the signature. The signature still validates for the original bytes, but Acrobat reports the modification. Check what changed, and decide whether the change is acceptable.

Failure 7: The signature uses a deprecated algorithm. SHA-1 signatures or short RSA keys may validate in an older tool and fail in a current one. Ask the sender to re-sign with current algorithms.

Failure 8: The validator's clock is wrong. Time-dependent checks, including certificate validity and revocation at the signing time, depend on the validator's clock. A machine with a significantly incorrect clock may produce confusing results.

Failure 9: The file was re-saved by a tool that broke the signature. Some tools rewrite the file in a way that changes the signed bytes, which invalidates the signature. The result is an invalid signature, and the document was not tampered with maliciously, but the signature is no longer reliable. This is a reason to avoid re-saving signed documents with tools that were not used to sign them.

Failure 10: The trust store differs between machines. A signature that validates on one colleague's machine may show unknown on another, because the trust stores differ. Standardize the trust configuration for the teams that verify signatures, and record the configuration in the procedure.

A verification procedure for buyers and reviewers

For teams that receive signed PDFs regularly, a short, written procedure reduces errors and creates a record. The following steps are a practical baseline.

1. Confirm the type of signature. Ask whether the document carries a cryptographic digital signature, an electronic signature from a platform, or both. Do not accept a visual stamp as proof of integrity.
2. Open the document in Acrobat on a machine with your organization's trust configuration. Check the Signatures panel for the status summary.
3. For each signature, record the signer's name, the certificate issuer, the signing time and any timestamp, and the validity result.
4. Check whether the document was modified after signing, and whether the changes are acceptable.
5. Verify the signature independently with a second tool, such as pdfsig, and compare the results.
6. If the result is unknown or invalid, identify the cause using the failure list above, and request the appropriate action from the sender.
7. Confirm the signer's identity through a channel independent of the document, such as a known contact or a registered business record, if identity is material to the decision.
8. Store the signed document, the verification report and the decision record together.

For documents that matter to a contract, a regulatory filing or a personnel decision, the signature check is one part of the evidence. It establishes integrity and the certificate's involvement. It does not replace due diligence on the signer's authority to bind an organization or on the commercial terms.

Finally, if you are the signer, make your signatures verifiable. Use a certificate issued by a recognized authority, embed the full chain, include a trusted timestamp, and choose a format such as PAdES that supports long-term validation. Check your own signed document in Acrobat before you send it, so that the recipient does not discover a problem you could have prevented.

For more on how PDF permissions and encryption interact with signed documents, see our articles on PDF permissions and how to encrypt a PDF file. A signature does not restrict who may read a document, and encryption does not prove who signed it.