How to Verify a Signature in a PDF When It Says Not Verified

A signed contract lands in your inbox. You open it, and instead of a reassuring green tick there's a yellow bar across the top: "At least one signature has problems." Or you click into the signature and read "Signature validity is unknown."

Here's the thing that nobody puts in the banner. Those messages are usually about trust, not tampering.

A PDF signature check answers two separate questions. Did this file change after it was signed? And can your reader trace the signing certificate back to a root it recognises? The second question fails far more often than the first, and it fails for reasons that have nothing to do with the document. Adobe Acrobat Reader ships with its own list of trusted certificate authorities, and that list isn't the same as the EU Trusted List, or the one Windows keeps, or the one your bank's PKI team maintains.

So when a signature comes back not verified, you're normally looking at one of these:

• The signing certificate chains up to a root your reader doesn't carry. Nothing is wrong with the signature. Your copy of Acrobat simply hasn't been told to trust that issuer.
• The file changed after signing. A re-save, a flattened form field, or a pass through a mail gateway that "optimised" the attachment. This one is real, and it's the case worth catching.
• The certificate had expired by the time you opened it, and there's no trusted timestamp to prove it was still valid at the moment of signing.
• Revocation data can't be reached, so the check finishes as indeterminate rather than as a pass or a fail.

Four different situations, one identical warning. That's the actual problem with verifying a signature in a PDF, and it's why "just look at the tick" is bad advice.

Three minutes of work, and the order matters more than the tooling.

First, check there's a signature to verify at all

A picture of somebody's handwriting isn't a digital signature. Neither is a typed name in a script font, nor a JPEG pasted into a form field. Those carry no certificate, so there's nothing to verify, and no validator on earth will produce a verdict on them.

Open the Signatures panel in Adobe Acrobat Reader. On Windows and macOS it's the fountain pen icon down the left side of the window, or View, then Show/Hide, then Navigation Panes, then Signatures. Empty panel? Then the document was never digitally signed, and what you're looking at is decoration. Our guide to signing a PDF covers the difference between the two.

Then read the per-signature detail, not the banner

Right-click the signature in that panel and choose Show Signature Properties. Adobe's own documentation on validating digital signatures walks through the dialog. This is where Acrobat stops being vague: you get the signer's name, the issuing certificate authority, the signing time, and whether the document changed after the signature was applied.

Worth doing while you're in there: click Show Signer's Certificate and read the Subject field. More on why that matters further down.

Then get a verdict that names the failing check

Acrobat's summary is a single yes-or-no about whether Acrobat is happy. It won't tell you which of the four underlying checks went wrong, and that's the answer you need to do anything useful.

Run the same file through a validator that reports the checks separately. Chaindoc's PDF signature validation returns integrity, certificate chain, revocation status, timestamps and the PAdES profile as five distinct results, each with its own pass or fail. When something fails you can see whether the document was altered or your reader simply doesn't trust the issuer, which are wildly different problems with wildly different responses.

Plenty of people don't have Acrobat, and the free Reader is a 500 MB install for a job that takes one upload. A browser-based checker gets you there faster, and it sidesteps the trust-store problem entirely, because a server-side validator can be pointed at a trust list far broader than whatever your desktop happens to carry.

What separates a useful online checker from a useless one is the report. Ask for four things:

• Integrity as its own line. The hash was recomputed over the signed bytes and either matched or didn't.
• The certificate chain, with the issuer named. "Untrusted" without naming the root is not an answer.
• Revocation checked at the signing time, via OCSP or CRL, rather than against today's date.
• Timestamp status, because that's what pins the signing moment down when a certificate later expires.

Chaindoc runs those checks through the EU DSS library, the European Commission's own open-source validation code, with the EU Trusted List as the primary trust anchor and the large commercial certificate authorities on top of it. It handles all four PAdES baseline profiles, takes files up to 50 MB, and doesn't keep the document after the check. You confirm your email address with a one-time code first, which is worth knowing before you start.

Not a PDF? PAdES is only the PDF flavour of the same idea. Signed XML carries XAdES, a .p7m or .p7s wrapper carries CAdES, and .asice containers are ASiC. If you're holding a file your computer refuses to open at all, start with P7M and ASiC-E containers instead.

Honest answer first: phones are bad at this, and it isn't your fault.

Mobile PDF readers were built to display documents, not to run certificate path validation. The stock viewers on both mobile systems are the weakest link here.

On iPhone and iPad

Opening a signed PDF in Files, Mail or Books shows you the signature's appearance and nothing about its validity. There's no signature panel and no certificate detail, because iOS doesn't ship a PDF trust store for this purpose. A signed document can look perfect in Apple's preview while its cryptography is broken.

On Android

Adobe Acrobat Reader for Android does better. Tap the signature and you'll get a panel with the signer's name and a validity summary. What you won't reliably get is the certificate chain, the revocation status, or a timestamp verdict, and those are exactly the parts that decide the outcome.

What actually works on a phone

Use the browser. A server-side validator does the certificate work on its own infrastructure and sends back a full report, so the phone only has to render a page. Chaindoc's PDF check works this way and accepts a file straight from your phone's storage or from a cloud drive.

My own take: if a signature matters enough to check, check it on a machine where you can read the certificate subject properly. Verifying a signature in a PDF on mobile is fine for a quick yes-or-no on a document you already expected. It's thin evidence for a payment you're about to make.

PDF digital signature verification comes down to the same four tests, whichever tool runs them. Knowing what each one proves tells you how much a failure should worry you.

Integrity. The validator recomputes the hash over the bytes that were signed and compares it with the hash sealed inside the signature. One changed byte fails this. When integrity fails, the document genuinely isn't the document that was signed, and no amount of trust configuration will fix that.

Certificate chain. The signing certificate points at its issuer, which points at its issuer, up to a root. The validator has to reach a root it trusts. Fail here and you've learned something about your trust configuration, not about the file.

Revocation. Certificates get revoked when a private key leaks or an employee leaves. The check queries OCSP or a CRL, and the question is whether the certificate was revoked at the moment of signing. A certificate revoked last week doesn't invalidate a contract signed two years ago. Validators that compare against today's status get this backwards.

Timestamp. A trusted timestamp from a time-stamping authority fixes when the signature was created. Without one, you're relying on the clock of whoever signed, which is worth roughly nothing in a dispute. Timestamps are also what keep a signature checkable after the certificate expires, which is the whole point of the PAdES-BASELINE-T profile and above, defined in ETSI EN 319 142.

One pattern to remember: integrity failing is a document problem. The other three failing are usually configuration or infrastructure problems. Sort out which kind you have before you email the sender.

This is the part that surprises people, so it's worth being blunt about it. There is no single global list of trusted signing authorities. There are several, they disagree, and your verdict depends on which one your software consulted.

Adobe maintains the Approved Trust List, a set of certificate authorities that Acrobat and Reader trust out of the box. The EU maintains the EU Trusted List, which is the legal basis for qualified signatures under eIDAS. Microsoft keeps its own root program for Windows. A bank or a government agency running an internal PKI trusts its own root and nobody else's.

The same signed PDF can therefore be valid in one place and unknown in another, with no contradiction. Both answers are correct about the question they were asked.

Two practical consequences.

If a supplier's signature shows as unknown in Acrobat, look at who issued the certificate before you accuse anyone of anything. A national certificate authority outside the AATL, an internal corporate CA, or a qualified EU provider that Adobe hasn't picked up will all produce that message on a perfectly sound signature.

And if you need the eIDAS answer specifically, ask a validator that treats the EU Trusted List as its anchor. Qualified status isn't a property of the mathematics; it's a lookup against a list. Qualified trust service providers and the EU Trusted List explains how that lookup works and why a valid signature and a qualified one are different verdicts.

A green tick is narrower than it looks. It says this file came from the holder of this certificate and hasn't changed since. Everything below is outside its scope.

Who signed it

A signature can be cryptographically flawless and belong to the wrong company. Open the certificate subject and read the organisation name and any tax or registration identifier in it, then compare that against the counterparty you think you're dealing with. Payment-diversion fraud works by looking plausible, and a valid signature from an entity that isn't quite your supplier looks very plausible indeed. This is the check almost nobody runs, and it's the one that catches real fraud.

Whether the signature is qualified

Valid and qualified are separate answers. Qualified means the issuing service appears on a national trusted list with qualified status, which carries the legal weight of a handwritten signature across the EU. Most valid signatures aren't qualified, and for most documents that's fine. Our qualified electronic signature guide covers when the distinction actually bites.

Whether the document is binding

Signature validity is a technical verdict about a file. Enforceability depends on consent, capacity, the applicable law and whatever the contract itself says. A valid signature is strong evidence, not a legal conclusion.

Whether the contents are correct

Somebody can sign a wrong number perfectly. If the invoice amount looks off, the cryptography has no opinion on that. Validating an invoice signature works through where this bites in accounts payable.

Five patterns, all avoidable.

Trusting the banner and stopping there. The summary bar tells you Acrobat's mood, not which check failed. Open the panel.

Sending a screenshot as proof. An image of a green tick proves nothing to an auditor, a court or a counterparty. What proves something is the original signed file plus a validation report generated while the revocation responders were still answering. Store both.

Re-saving the file during the investigation. Covered above, and it happens constantly. The signature was fine until somebody opened it in a tool that helpfully rewrote it.

Checking validity today instead of at signing time. Certificates expire. That's their normal end state, not a defect. A 2023 contract signed with a certificate that expired in 2024 is perfectly sound, provided a timestamp proves when the signing happened.

Adding trusted roots until the warning goes away. Tempting, and it converts a useful alarm into silence.

The summary worth keeping: when you get signature not verified in PDF, find out which of the four checks failed before you do anything else. Integrity is a document problem and needs the sender. The other three are usually trust plumbing, and they're yours to fix. Chaindoc's verification hub works out the format for you and reports each check on its own line, for PAdES, XAdES, CAdES and ASiC alike.