The short answer
Signature validity is UNKNOWN means Acrobat checked the maths, found the document unchanged, and then could not connect the signing certificate to any trust anchor it holds. It is a trust problem, not a tampering problem; a modified file produces a different and harsher verdict. Acrobat answers that trust question entirely offline, against local copies of two lists it refreshes on a schedule, and the Adobe Approved Trust List is downloaded roughly every 90 days. That is why one reader sees a green check and another sees a warning on the same file. A recipient can patch their own machine in about thirty seconds. Only the signer can fix it for everybody.
What the unknown verdict actually means
Acrobat asks two separate questions of every signature, and reports on both in one line. The first is whether the bytes of the document still match what was signed. The second is whether the certificate that produced the signature belongs to somebody Acrobat has a reason to believe in. An unknown verdict is a yes to the first question and a shrug at the second.
That distinction matters more than it sounds, because the yellow warning bar reads to most people as an accusation. It is not. The document in front of the reader is byte-for-byte the document that was signed. What Acrobat is declining to assert is who did the signing. Somebody with a self-signed digital ID, somebody using an internal corporate certificate authority, and somebody using a perfectly reputable commercial CA that this particular copy of Acrobat has not heard of yet all land in the same place.
The practical consequence is that the reader has no way to tell those three cases apart from the warning bar alone. Neither do you, if you are the one being told your signed contract looks broken. So the first move is always to open the signature properties and read what Acrobat says about the certificate chain, rather than reasoning from the colour of the banner.
Unknown, invalid, or valid: telling them apart
Acrobat has three outcomes and they need three different responses. A valid signature needs nothing. An unknown signature is a trust gap that a trust list refresh often closes. An invalid signature means the document changed after signing or the certificate was revoked, and no amount of trust configuration will move it. Applying the unknown fix to an invalid signature wastes an afternoon.
| What Acrobat reports | What it proved | What to do |
|---|---|---|
| Signed and all signatures are valid | Document unchanged, signer identity established | Nothing |
| At least one signature has problems, with validity reported as unknown | Document unchanged, signer identity not established | Refresh the trust lists; if that fails, the certificate is the problem |
| At least one signature is invalid | Document altered after signing, or certificate revoked | Get a clean copy and sign it again; investigate the revocation |
| Signature valid, but reported as not enabled for long-term validation | Valid today, with an expiry date attached to that answer | Re-sign with a timestamp before the certificate expires |
The fourth row is the one that catches people out, because everything looks fine at the moment of checking. It is a green check with a shelf life.
Why Acrobat refuses to trust the certificate
Acrobat trusts a signing certificate only when it can build a chain from that certificate up to a root it already holds. There are exactly three ways a root gets into that store: it arrived in the Adobe Approved Trust List, it arrived in the European Union Trusted List, or a human on that machine added it manually. A certificate outside all three has no path to a trusted verdict, regardless of how strong the cryptography behind it is.
This trips up two groups in particular. The first is anyone signing with a certificate their own organisation issued. Internal certificate authorities are the right tool for internal systems, and they are invisible to every reader outside the domain. The second is anyone who assumed that a certificate trusted by web browsers is therefore trusted by Acrobat. It is not the same trust store, it is not the same programme, and a TLS certificate cannot sign a document in the first place.
There is also a quieter failure worth naming: a chain that is broken rather than untrusted. If the signing application embedded only the end certificate and left out the intermediate, Acrobat has a root it trusts and a leaf it cannot connect to that root. The signature properties will say the certificate path could not be built, which reads similarly in the banner and has a different cause. Signing tools that talk to the CA correctly embed the full chain for you, which is one reason hand-assembled signing scripts produce more of these than commercial signing software does.
The two lists Acrobat checks, and how stale they get
Acrobat does not contact anyone to decide whether it trusts a signer. It consults local copies of two lists. The Adobe Approved Trust List is Adobe's own programme, and Acrobat and Reader version 9 and later download it automatically about every 90 days, enabled by default. The European Union Trusted List is a separate store with its own checkbox, distributed as a periodically refreshed snapshot rather than a live query.
Two details in Adobe's own documentation explain most of the strange behaviour people report. The first is that the 90-day timer only advances when the application is actually used for signatures, which means opening a signed document, signing one, or opening the signature panel. A machine that handles a signed PDF twice a year can be carrying a list that is far older than 90 days. The second is that these are two independent settings, so a reader can have the Adobe list current and the European one switched off entirely.
The European list matters more than the English-language advice on this problem usually admits. Under Regulation (EU) No 910/2014 each member state publishes a register of its qualified trust service providers, and Acrobat's copy of that data is what allows it to label a signature as qualified rather than merely trusted. If your counterparty is a European bank, notary, or public authority, this is the list their signature depends on, and a reader with that box unticked will see an unknown verdict on a signature that is legally the strongest kind there is.
Valid on one machine, unknown on another
The same file genuinely can produce different verdicts on different desks, and neither reader is wrong. Trust is evaluated locally against whatever that installation happens to hold, so the answer depends on the freshness of two lists, the state of two checkboxes, and whether anyone ever added the certificate to that machine's trusted identities by hand. The signature bytes are identical throughout.
We see this most often in the support queue in one specific shape. The person who bought the certificate has been signing and opening signed documents for weeks, so their trust list is current and their own test file looks perfect. The recipient is a finance department that opens a signed PDF once a quarter on a locked-down desktop with outbound traffic filtered, so their list has not been refreshed in a long time and cannot refresh itself. Both sides then argue about a certificate that was never the problem.
Corporate environments make this worse in a way worth planning for. Administrators can pin the trust configuration through enterprise policy, and in some deployments the automatic download is deliberately disabled so that the trust store stays under change control. That is a defensible decision, and it means your documents will be judged against a list somebody else curates on their own timetable. Testing with a colleague on the same network proves very little about how a customer will see the file.
It was valid last year and now it isn't
When a signature that verified cleanly starts reporting unknown and nobody touched the file, the signing certificate has almost always expired. Acrobat needs to establish that the certificate was valid at the moment of signing. Without an embedded RFC 3161 timestamp and the revocation data collected at that moment, it has no evidence of when the signing happened, so it stops asserting anything once the certificate lapses.
This is what long-term validation means in practice, and Acrobat tells you which side of it a document sits on. Open the signature properties and it reports either that the signature is enabled for long-term validation, or that it is not and names the date after which it will stop verifying. Reading that line on a document you signed last week costs nothing and tells you precisely how long your signature has left.
The uncomfortable part is that the decision is made at signing time and cannot be repaired afterwards. Nobody can retroactively prove that a certificate was good three years ago. If a document needs to hold up for the length of a mortgage, a warranty, or a statutory retention period, the timestamp has to be there from the start. This is the same mechanism that keeps signed software verifying after its certificate expires, covered in more depth in our guide to timestamping and long-term validity.
What a recipient can do (and why it doesn't scale)
If you received the file and just need to read it, refresh the trust lists. Open Preferences, select Trust Manager, confirm that loading trusted certificates from an Adobe server is enabled, and click Update Now. Do the same under the European Union Trusted List section if the signature came from an EU provider. Close the document and reopen it, because the verdict is calculated when the file loads.
That resolves the majority of cases where the signer used a mainstream commercial certificate authority and the reader's copy was simply out of date. If the update itself fails, the machine cannot reach Adobe's servers, which on a managed desktop usually means a proxy or an outbound filter and belongs with the IT team rather than with the signer.
The other piece of advice you will find everywhere is to open the signature panel, select the certificate, and add it to your trusted identities. It works, and it is the wrong habit to teach. It changes one computer, it survives nothing, and it trains people to click through a warning that exists to be read. Use it to confirm a diagnosis, then stop. If you are the publisher and you are asking recipients to do this, you have moved your trust problem onto people who have no way to evaluate it.
What the signer has to do instead
There is only one fix that reaches every reader: sign with a certificate whose issuing authority already sits on the Adobe Approved Trust List, and embed a trusted timestamp with it. Then a first-time reader on a default installation gets a trusted verdict with no configuration, no instructions, and no support call. Everything else on this page is a workaround for not having done that.
Three things decide whether that happens, and they are worth checking in order. The certificate has to be a document signing certificate rather than a TLS or code signing certificate, because the extended key usage in the certificate governs what it is allowed to sign. The issuing CA has to be on the trust list you need, which is the Adobe list for general distribution and the European list where a qualified signature is the requirement. And the signing step has to request a timestamp, which in most tools is a setting rather than a default.
If you are choosing a certificate for this, the practical filter is short. Confirm the CA appears on the Adobe Approved Trust List for the product you are buying, not merely somewhere in the vendor's catalogue. Confirm a timestamp server is included. Then decide between a hardware token and a cloud signing service on operational grounds, since the trust outcome is identical either way. Our document signing certificates are issued from an AATL-listed authority and sign from a virtual card rather than a physical device, which is the part that matters if the signing has to happen from more than one location.
For a wider view of what these certificates prove and where they differ from the other kinds, start with what a document signing certificate actually proves, then work through the signing procedure itself with the timestamp setting turned on.
A checklist before you send the file
Five checks catch almost every version of this problem before a recipient ever sees it, and all five take a couple of minutes on the first document you sign with a new certificate. Run them once, then trust the workflow.
- Open your own signed file on a machine that has never seen the certificate. Your own computer is the least representative test there is, because it already trusts everything you have signed with.
- Read the certificate path in the signature properties. A complete chain ending at a root Acrobat holds is the outcome you want. A missing intermediate shows up here and nowhere else.
- Confirm the signature reports as enabled for long-term validation. If it names a date instead, the timestamp is missing and every document you have signed so far has the same countdown on it.
- Check the certificate's own expiry against the life of the document. With a timestamp in place this stops mattering, which is exactly why the timestamp is not optional.
- Send one test file to the counterparty who will judge the real one. For anything going to a bank, a registry, or a public authority, their reader configuration is the only verdict that counts.
None of this makes a signature unbreakable, and no certificate can promise that. What it does is remove the two failure modes that generate nearly all the complaints: a trust anchor the reader does not have, and a signature with no proof of when it was made.