Verify PDF Signatures

About the Verify PDF Signatures

Check the digital signatures in a PDF the way a careful PDF reader does, and see the reasons behind every verdict. For each signature you get four answers: whether the signed bytes are intact, whether anything was changed after signing (and what kind of change), whether the signer’s identity can be verified through their certificate chain, and when it was signed — certified by a timestamp authority, or only as claimed by the signer’s computer.

The signatures are verified cryptographically in your browser with Web Crypto and PKI.js; the file is never uploaded. Chains are checked against the root certificates of the Root Certifying Authority of India (CCA), which Indian digital signature certificates (DSC) and eSign chain to, and against any root certificate you add. Revocation (OCSP/CRL) is not checked: that would mean contacting the certificate authority, and this tool makes no network requests.

Common uses

• Checking a signed contract, offer letter, invoice or certificate before relying on it.
• Finding out who signed a PDF and with which certificate, and whether that certificate was valid then.
• Spotting documents changed after signing, including edits hidden in later incremental updates.
• Confirming that long-term validation data or document timestamps were added correctly.

What is checked

• Byte range. A PDF signature covers the whole file as it was when signed, except the signature value itself (ISO 32000-1, section 12.8). The tool checks that the signed ranges start at the beginning of the file, leave exactly the signature value unsigned and stay inside the file.
• Integrity. The hash of the signed bytes must equal the message digest inside the CMS signature (RFC 5652), and the signature must verify with the public key in the signer’s certificate. PAdES (ETSI.CAdES.detached), adbe.pkcs7.detached, adbe.pkcs7.sha1, the old adbe.x509.rsa_sha1 and document timestamps (ETSI.RFC3161) are supported; RSA, RSA-PSS and ECDSA keys.
• Changes after signing. Later incremental updates are read object by object, and the pages, each page’s settings and the document-wide settings are compared with the version that was signed. Added signatures, timestamps and validation data are expected; changed page content, pages added, removed or reordered, changed page resources, comments, filled form fields, replaced signature appearances, changed document-wide settings (such as an action that runs on opening) and data added outside a regular update are reported.
• Identity. Each certificate in the chain must be signed by the next one; every issuer below the root must be a certificate authority allowed to sign certificates (basic constraints, key usage and path length); and every certificate, the root included, must be valid at the signing time (RFC 5280, section 6). The chain is trusted when it ends at a root you trust.
• Time. A signature timestamp or document timestamp (RFC 3161) is verified against what it covers, and it certifies the time only when it was signed with a timestamping certificate that chains to a trusted root. Otherwise the time shown is what the signer’s computer, or the unverified timestamp, claims.

The bundled roots and adding your own

The roots of the Root Certifying Authority of India — CCA India 2011, 2014, 2015 SPL and 2022 — are bundled, as listed with their SHA-256 fingerprints in the Microsoft Trusted Root Program on CCADB. Older roots still verify signatures made while they were valid. A root is trusted by its name and public key, as RFC 5280 describes trust anchors.

For any other authority — a European trust service provider, a company CA, a test CA — add its root certificate. Get it from the authority itself, not from the PDF you are checking: a root supplied by the same person who sent the document proves nothing.

What a valid signature means — and doesn’t

A cryptographically valid signature shows that the signed version of the file has not changed since the private key belonging to the certificate signed it. It doesn’t show that the signer had authority to sign, that the content is true, or that the certificate was not revoked. In India, section 3 of the Information Technology Act, 2000 provides that a subscriber may authenticate an electronic record by affixing a digital signature, and that any person can verify the record with the subscriber’s public key. Whether a particular signed document is legally valid or admissible depends on the law that applies and the facts — this tool reports technical checks only and is not legal advice.

Long-term signatures (PAdES levels B-T, B-LT and B-LTA in ETSI EN 319 142-1) add timestamps and validation data so that a signature can be validated long after its certificate expires; the tool shows which of those the file carries.

Limitations

• Revocation is not checked: a certificate revoked before signing still shows as valid here. Check revocation with the certificate authority or with a PDF reader that checks online.
• Only the bundled CCA India roots and the roots you add are trusted. Adobe’s and the EU’s trust lists are not included, so signatures from those authorities show the identity as not verified until you add their root.
• Signature policies, commitment types and the full PAdES conformance rules are not evaluated, and certificate policies and name constraints are not checked.
• In encrypted PDFs, signatures are verified, but field names and reasons may be unreadable.
• Changes after signing are worked out object by object and by comparing the pages and document settings with the signed version; a cleverly built update could still escape that. When it matters, download the version that was signed and read that.
• A drawn or pasted image of a signature is not a digital signature and can’t be verified.

Privacy

On this device: nothing is sent

The PDF and any root certificates you add are read and checked by your browser on your device. Nothing is uploaded, and nothing is stored after you leave the page.