PAdES signature verification

PAdES (PDF Advanced Electronic Signatures) is an ETSI standard for embedding digital signatures in PDF files. It defines four levels of assurance, from basic signatures to long-term archival formats. PAdES signatures are legally recognised under the EU eIDAS regulation as advanced or qualified electronic signatures.

Upload your signed PDF and the EU Digital Signature Service (DSS) library validates it. The check covers four things: cryptographic integrity (the document wasn't modified), certificate validity (the signer's certificate was valid at signing time), timestamp verification, and certificate revocation status via CRL and OCSP. It typically takes a few seconds.

It means four conditions are met: the cryptographic signature is mathematically correct, the document hasn't changed since signing, the signing certificate was valid at that time, and the certificate chain traces back to a trusted root authority. If any of these fail, the signature is marked invalid.

The most common reasons: someone edited the PDF after it was signed, the signing certificate expired or was revoked, the certificate chain can't be traced to a trusted root, or the signature format doesn't comply with PAdES standards. The detailed report shows exactly which validation step failed, so you'll know what went wrong. Not sure this is even a PAdES signature? Chaindoc's signature verification hub detects the format automatically and checks PAdES, XAdES, CAdES and ASiC alike.

Acrobat shows this warning more readily than a strict eIDAS check would, so it doesn't always mean the signature is broken. Three causes cover most cases. Most often, the signing certificate's root isn't in Acrobat's own trust store — Acrobat checks against its own list of trusted providers, not the EU Trusted List, so a signature can be fully valid under eIDAS and still get flagged here. Less often, the document changed after it was signed — even a re-save or a flattened form field breaks the signature for real. Occasionally the signing certificate expired and there's no timestamp proving it was still valid at signing time. Acrobat's summary banner doesn't say which of the three applies. Run the same PDF through the checker above and the report names the exact step that failed.

No. Chaindoc processes the PDF for verification only and doesn't keep the file after the check completes. The verification result and signature metadata are retained in your history for audit purposes, but the document content itself isn't stored.

Chaindoc uses the EU Trusted List (EUTL) as the primary trust anchor, which covers all qualified trust service providers under eIDAS. Major commercial CAs (like DigiCert, GlobalSign, and others) are also trusted. If you need to validate signatures from an internal PKI, you can configure custom trust anchors. Check pricing for details on custom trust anchor configuration.

Yes. The tool detects and validates every signature in the PDF separately. The report shows results for each one, including incremental signatures and any modifications made between signing rounds. This is useful for contracts that go through sequential signing workflows where multiple parties sign at different times.

Yes — each signature format has its own tool. For XAdES signatures in XML files use XAdES verification, for CAdES signatures in .p7m or .p7s files use CAdES verification, and for signed ASiC containers (.asice, .asics) use ASiC container verification. This page verifies PAdES signatures embedded in PDF documents.