At least one signature has problems: why signature validity is unknown and how to fix it

You open a signed contract and a yellow bar sits across the top of the page: "At least one signature has problems." It reads like an accusation. Usually it isn't one.

Acrobat runs two separate checks on every signature, and Adobe's own signature validation guide says the status depends on both. One is document integrity: have the signed bytes changed since the signature was applied? Then there's the signer's identity: does the signing certificate chain up to a certificate your copy of Acrobat trusts, and was it valid at the time Acrobat checks against? If either check isn't clean, for any signature in the file, you get the banner.

In practice the identity check fails far more often. Your reader hasn't been told to trust whoever issued the certificate, so the file is fine and the gap is the trust list on your computer. That's yours to fix, not the sender's.

Less often, and worth catching, the document really did change after signing. This table sorts every message into one of those two piles, and a validator that reports each check on its own line tells you which pile you're in.

Open the Signatures panel and the banner turns into something more specific. Under a signature, the line you'll see most often is "Signature validity is unknown", and below it sit two sentences that matter more than the headline.

One says whether the document has been modified since the signature was applied. The other says whether the signer's identity is known. When the first reads "Document has not been modified since this signature was applied" and the second says the identity is unknown, you've learned the important part: the content is exactly what was signed, and Acrobat just can't vouch for who signed it.

There are three ordinary reasons for that:

• The issuing CA isn't on any list your Acrobat carries, or your copy of those lists is out of date.
• The certificate is self-signed, and no reader trusts a self-signed ID on its own.
• Revocation data couldn't be fetched, so the check stopped short of a yes.

When signature validity is unknown in a PDF from a government portal or a large supplier, it's almost always the first reason.

There's no single global list of trusted signers. Acrobat builds its verdict from a short stack of sources, so the same signed PDF can be valid on one desk and unknown on the next without anyone being wrong.

First comes the Adobe Approved Trust List, Adobe's own program for certificate authorities and timestamp providers whose certificates Acrobat and Reader trust out of the box. When we counted the AATL members page on 14 October 2026, it listed 92 providers: commercial CAs such as DigiCert, GlobalSign and Sectigo next to national bodies such as CCA India and Brazil's ITI. If your signature's issuer is on that page and the warning is still there, your local copy of the list is the likely culprit.

Next is the EU Trusted List. Under Article 22 of the eIDAS Regulation, every member state publishes a list of its qualified trust service providers, and Adobe's EUTL page puts the total at more than 400 active and legacy providers. Acrobat doesn't query those lists live. It keeps a snapshot limited to providers of signing certificates, seal certificates and timestamps, and refreshes it about once a month, which is why a newly listed provider can read as unknown for a few weeks.

Last comes your own machine: certificates you've added to Trusted Certificates and, on Windows, optionally the roots in the Windows certificate store, which Acrobat can be set to trust for signature validation.

Anything outside those three produces the warning. An internal company CA will, and so will a self-signed ID someone made in their PDF editor, or a national CA that isn't on either list. Honestly, this is the part most guides skip, and it changes what you should do. Before you trust anything by hand, check whether the issuer is already listed. If it is, update. If it isn't, you're making a trust decision, and knowing what a qualified certificate certifies is worth five minutes first.

India is where "signature validity is unknown" gets searched most, and the files are usually official: an income-tax acknowledgement, a GST registration certificate, an MCA filing, a university mark sheet, a loan agreement signed through Aadhaar eSign. Each carries a certificate from a Certifying Authority licensed by the Controller of Certifying Authorities (CCA).

Here's what older guides get wrong. CCA India and eMudhra both appear on Adobe's AATL members page, so the first fix for signature validity is unknown on an Aadhaar or DSC-signed PDF isn't importing anything. It's step 4: Update Now under the AATL, then reopen the file.

If that doesn't clear it, see which root the chain from step 3 ends at. The CCA lists its roots with their dates on its root certificate page: CCA India 2014 expired on 5 March 2024, and CCA India 2022 runs to 2 February 2042. A chain ending at a root your Acrobat doesn't list is where a manual import is justified. Download that root from cca.gov.in itself, compare the fingerprint, then trust it as in step 5.

One limit on our side: Chaindoc's validator anchors on the EU Trusted List, so a CCA-issued file comes back with an integrity verdict and an unresolved chain. For a verdict on the Indian chain itself, Acrobat with an updated AATL is the better tool.

Acrobat isn't the only reader that warns you, and some readers don't check at all.

Foxit PDF Reader runs its own validation. Its manual says a signature can show as "unknown" or "could not be verified" until you add the issuer to its Trusted Certificates list, and it can also trust roots from the operating system's certificate store if you switch that on. The manual doesn't mention the AATL or the EU lists, so a PDF that's green in Acrobat can be unknown in Foxit on the same machine.

macOS Preview is the opposite case. Apple's guide covers capturing a signature with the trackpad, the camera or an iPhone, and says nothing about checking certificates. A signed file can look perfect in Preview without Preview having checked anything. If you're not sure which kind of signature you're holding, here's the difference between a drawn signature and a certificate signature.

Phones vary by app. If your viewer shows no signature panel and no certificate details, it hasn't checked anything, however tidy the page looks.

Sometimes the panel says the document has been altered or corrupted since it was signed, or marks the signature as invalid. That's the integrity check failing, and no trust setting touches it. Use View Signed Version in the Signatures panel to see exactly what was signed, compare it with what you received, and ask the sender for the original file.

One distinction helps. A certified PDF can allow form filling or comments after signing, and Acrobat lists those as permitted changes, not failures. "At least one signature is invalid" is a different message from "has problems": it calls for a phone call to the sender, not a settings change.

If recipients keep reporting the banner on files you sign, the fix is on your side, and it's mostly a certificate question.

• Stop using a self-signed ID for documents that leave the building. Acrobat and Foxit will both create one in a minute, and no recipient's reader trusts it by default.
• Get a PDF signing certificate from a listed issuer. A document signing certificate from an AATL member opens as trusted in Acrobat and Reader. One from a qualified provider on an EU trusted list is recognised through Adobe's EUTL snapshot too, after its update lag.
• Add a trusted timestamp if your tool offers one. ETSI's PAdES standard describes the B-T level as adding a token that proves the signature existed at a given time, so a validator can show it predates the certificate's expiry.
• Open one signed file on a computer that isn't yours before you send a batch.

Signing through a service changes who holds the certificate, not how readers judge it. A PDF signed with Chaindoc is a PAdES file like any other, so everything above about the AATL and the EU lists applies to it. Chaindoc's qualified-signature lane signs at PAdES-BES, which carries no timestamp token, so Acrobat reports the signing time from the signing system's clock rather than from a timestamp server. If you send documents for signature to people who open them in Acrobat, that's worth knowing before the first one asks.

The green tick answers a technical question. ETSI's validation standard, EN 319 102-1, calls the best outcome TOTAL-PASSED and adds that this "does not necessarily mean that the signature is useful for a particular purpose." Three things sit outside it.

Who signed

A flawless signature can belong to the wrong company. Open the certificate's Subject and compare the organisation name with the party you're actually dealing with. Payment-diversion fraud depends on a name that's nearly right.

Whether it's qualified

Under Article 32 of eIDAS, a qualified signature needs a qualified certificate from a qualified provider, valid at signing, created on a qualified signature creation device, with the signed data intact. Acrobat states qualified status only when the chain resolves in its EU snapshot. Here's when a qualified signature is the legal bar.

Whether the contents are right

Somebody can sign a wrong invoice total perfectly well.

So how do you check digital signature validity properly? Integrity, a trusted chain, revocation at the signing time, then your own reading of the subject. That last step is the one nobody automates.

Maybe you'd rather not touch trust settings on a work laptop, or you don't have Acrobat at all. A browser-based validator does the certificate work on its own server, which also makes it the practical route on a phone.

Chaindoc's verification service runs the checks through the EU DSS library, with the EU Trusted List and the large commercial CAs as trust anchors, and returns integrity, chain, revocation, timestamps and the PAdES profile as separate results. You confirm your email address with a one-time code before the first report. If integrity passes and only the chain fails, the warning is about trust, and you can decide calmly what to do in Acrobat.

Not a PDF? The same service handles XAdES, CAdES and ASiC files. And if the question is bigger than one signature, start with checking whether a received file is genuine.

When at least one signature has problems, the order doesn't change: find out which check failed, fix trust only on your side, and send integrity failures back to the sender.