Open two signed PDFs in Adobe Acrobat and you'll sometimes see two very different results: one shows a clean blue ribbon and "Signed and all signatures are valid" the instant it opens, while the other shows a yellow triangle warning that the signature's validity is unknown. Both documents might be cryptographically signed correctly. The difference is almost always the AATL.
What AATL actually is
AATL stands for the Adobe Approved Trust List — a list of certificate authorities that Adobe has vetted and bundled directly into Acrobat and Reader. When a PDF is signed with a certificate that chains up to one of these trusted authorities, Acrobat already has everything it needs to verify that chain locally, the moment the file is opened. No internet connection, no manual trust configuration, no clicking "trust this certificate" — it just shows as valid.
A certificate that isn't chained to the AATL can still produce a technically valid signature, but Acrobat has no built-in reason to trust the issuer, so it shows a warning instead of a green tick — even though nothing about the document itself was tampered with.
Why the chain matters more than the signature
It's easy to assume that "signing" and "being trusted" are the same step. They aren't. Signing proves the document hasn't changed since it was signed and identifies who signed it. Trust is a separate question: does the verifying software have a reason to believe that identity is legitimate?
The AATL answers that second question in advance. Because Adobe has already vetted the issuing authority and shipped that trust into every copy of Acrobat and Reader, the recipient's software doesn't need to do any extra work — the chain of trust is already sitting on their machine before your document ever reaches them.
What this looks like in practice
- A document is signed using a certificate issued by an AATL-listed authority (most Indian licensed Certifying Authorities issuing Class 3 / DSC certificates for organizational use fall into this category, depending on the specific CA and certificate type).
- The signer's private key — held on a USB token or inside an HSM — signs a hash of the document. The key itself never leaves the device.
- When the recipient opens the PDF in Acrobat or Reader, the software walks the certificate chain from the signature back up to the AATL-listed root, confirms it, and shows the verified checkmark immediately.
Long-term validation: the other half of trust
A signature that verifies today should ideally still verify years later, even after the signing certificate itself has expired. That's what PAdES long-term validation (LTV) is for — it embeds the certificate chain, revocation status, and timestamp information directly into the signed PDF at signing time, so Acrobat can still verify the signature's validity long after the original certificate is gone.
This matters most for exactly the kind of documents enterprises can't afford to have quietly become unverifiable: board resolutions, statutory filings, and contracts that may need to be checked years down the line.
The practical takeaway
If a signed PDF needs to show as trusted the instant someone opens it — not after they manually add a certificate exception — the certificate behind that signature needs to chain up to the AATL, and the signature itself needs to be built with long-term validation in mind. Get the certificate and the signing process right once, and every document that follows inherits the same instant, trusted appearance.
See a trusted signature land in real time
We'll sign one of your own sample PDFs against a test certificate and show you exactly what the recipient sees.