Almost every official document you now receive arrives as a signed PDF. Your RTI reply, the CIC order, the GST registration certificate, the DigiLocker mark sheet, the court order your lawyer forwarded. Each one carries a digital signature, and almost nobody checks it properly, because a green tick appears and the matter feels settled.
The green tick is real and it is worth something. It just proves far less than most people assume. This page sets out the five separate things a signed PDF can tell you, in the order you should ask them, and it is honest about the two questions no software can answer for you.
When a signature validates, two facts have been established, and only two.
Now the things a green tick does not prove:
Hold on to that distinction. Almost every dispute about a digitally signed document turns out to be about authority or content, not about cryptography, and the tick was never going to help with either.
These are not invented. They track what the Government of India's own guidance says a verifier must do. The e-governance guidelines issued by the Department of Information Technology state that applications “should also undertake Root chain verification and CRL verification in addition to the Public Key verification while doing the Digital Signature verification”, and the worked example in the same document runs signature verification, trust chain verification and CRL verification as separate steps.
This is the integrity check, and it is the one that is almost always done for you. Any competent verifier hashes the signed portion of the document and compares it against the hash sealed inside the signature.
What to look for beyond the pass or fail: whether the signature covers the whole document or only part of it. A PDF can be signed and then legitimately added to, with a second revision appended. A verifier that reports only “valid” hides this. A verifier that reports “signed version 1 of 3” is telling you something you need to know, because pages may have been appended after the officer signed.
A certificate is only worth what its issuer is worth. In India the chain has a defined top. The Controller of Certifying Authorities has established the Root Certifying Authority of India, and the CCA's own page states the position plainly: “The CCA has established the RCAI under section 18(b) of the IT Act to digitally sign the public keys of CAs in the country”, and “these keys are signed by the CCA can be verified by a relying party through the CCA's website or CA's own website”.
So the question is not “is this certificate valid” in the abstract. It is: does this signer's certificate chain up, through a licensed Certifying Authority, to the Root Certifying Authority of India?
There are 23 licensed Certifying Authorities listed by the CCA, including Safescrypt, IDRBT, (n)Code Solutions, e-Mudhra, CDAC, Capricorn, Protean, Vsign, CSC, IDSign, CDSL Ventures, Panta Sign, XtraTrust, ProDigiSign, SignX, Care 4 Sign, Speed Sign, RISL, IGCAR and the certifying authorities of the Indian Army, Navy, Air Force and Assam Rifles. If the issuer of a certificate on an “official” document is not on that list, that is the moment to stop and ask questions.
The common trap here is a signature that shows as valid on your machine but for the wrong reason. A generic PDF reader may trust a certificate because of a commercial root store it ships with, not because the certificate chains to the India root. For an Indian government document, chaining to the RCAI is the point.
This is the check almost everyone skips, and it is the one that catches real fraud.
A certificate has a validity window. It can also be cancelled inside that window, if the token was lost, the holder left the organisation, or the key was compromised. Cancellation is published in a Certificate Revocation List. The Government of India guidelines are direct about this: “Before relying on a signature the CRL should also be checked to ensure that the corresponding DSC has not been revoked.”
Two distinct questions live inside this check, and they are easy to confuse.
Open the certificate and read the subject. The name in the certificate is the name the Certifying Authority verified. Compare it against the name and designation printed on the document.
Look for the organisation field too. A certificate issued to an individual in a personal capacity is a different thing from one issued to a named officer of a named department, and on an official communication you would expect the latter.
This is where software runs out and you begin. No verifier can tell you whether that person was authorised to sign that document. If the designation on the certificate does not match the authority the document claims, that is a question for the department, and on a public authority it is a question you can put in writing under the Right to Information Act.
A printout is not a signed document. It is a picture of one. Anyone can edit a PDF, print it, and hand you paper that looks identical to the real thing, because the signature lives in the file and not in the ink.
This is why so many Indian government documents now carry a QR code. The code is the bridge back to the original: scan it, retrieve the signed file the issuer actually published, and compare. A verification that starts from the paper and never reaches the signed original has not verified anything.
Certificates expire, typically after one to three years. Once the signing certificate has expired, verifying an old document gets harder, because the verifier needs the issuer certificates and the revocation lists as they stood on the day of signing, not as they stand today.
The CCA's guidance acknowledges this directly: Certifying Authorities make issuer certificates and CRLs available until the DSCs expire, and for documents that must be verified long afterwards, the CCA recommends using a long term archival signature format. The e-governance guidelines note that CAs are mandated to store certificates, root chains and CRLs for seven years under the Rules made under the IT Act.
The practical lesson for a citizen is short. Verify a signed document when you receive it, not when you finally need it. Save the verification report along with the file. A property document, a pension sanction or a degree certificate may need to be relied on twenty years from now, long after the certificate that signed it has gone.
Here is a fact that surprises people. Opening a signed PDF in the built-in viewer on a phone or in a browser does not verify anything.
Google's own guidance for the digitally signed invoices it issues in India says it plainly: “To validate a digital signature, you must use Adobe PDF software, such as Adobe Acrobat Reader”, and “PDF viewers such as Apple's Preview or Chrome's PDF Viewer cannot be used.”
So on an iPhone or iPad, tapping a signed PDF in Files or Mail shows you the document and tells you nothing about the signature. The blue rosette drawn on the page is a picture printed inside the PDF. It is not a verification result, and a forged document can carry an identical picture.
There are ways to do this properly. On a desktop, Adobe Acrobat Reader will validate, provided the India root is in its trust list. There are web-based validators. What has been missing on iOS is a way to run the full set of checks on the device where the document actually arrives, which for most people is the phone.
Disclosure. SureSign is built by Big Helpers, the same organisation that publishes RTI Wiki. We are describing our own app. The five checks above stand on their own and you can run them with any tool that performs them properly.
SureSign is a free iOS app that exists for this specific job: to tell you, in plain language, what was actually checked in a signed PDF before you rely on it. Mapped against the five checks above:
| Check | What the app does |
|---|---|
| 1. Altered after signing | Examines signature integrity and reports change records, so an appended revision shows up instead of hiding behind a single green tick |
| 2. Chains to the India root | Examines the certificate and issuer details and produces a trust summary rather than a bare pass or fail |
| 3. Live at signing, revoked since | Reports certificate information as part of the trust assessment, so validity and status are shown rather than assumed |
| 4. Signer identity | Shows signer details and certificate subject, so you can compare them against the designation printed on the document |
| 5. Paper versus original | Scans the QR code on a printed document, retrieves the signed original and verifies that, which is the only way to close the paper gap |
Beyond the five, it does two things worth knowing about. It verifies in batch with CSV export, which matters if you are checking a folder of certificates rather than one document. And it keeps a Trust Passport and saved reports, which is exactly the record you want to have kept when the expiry trap above catches up with a document years later.
On handling: core features work without an account, uploads are processed and discarded unless you save them to the optional encrypted vault, reports stay on the device, and the listing states the app carries no ads, analytics, advertising identifiers or tracking SDKs. The vault uses a password you choose, with the app stating that passwords are not stored and not recoverable, so a forgotten vault password means the contents are gone.
It is iOS only at present, and it requires iOS 13 or later. On a desktop, Adobe Acrobat Reader remains a perfectly good way to run these checks.
Signed PDFs you are likely to receive, and where checking them actually matters:
If a document fails a check and the issuer is a public authority, you are not stuck. An RTI application can ask for the record of what was issued, by whom and on what date. Draft one with the AI RTI Drafter, work out when the reply falls due on the RTI Timeline Tracker, and if it does not come, the appeal route is set out in The RTI Playbook.
Not necessarily. A picture of a signature or a rosette drawn on the page is just artwork inside the file, and anyone can paste it. A real digital signature is a cryptographic object attached to the document, and the only way to know it is there is to run a verifier. Never treat the visible mark as proof.
It means the integrity check passed, so the document has not been altered, but your software does not trust the certificate chain, usually because the India root is not in its trust list. It is not a statement that the signature is fake. Add the CCA root chain to your reader's trusted identities, or use a verifier that already knows the India hierarchy, and check again before concluding anything.
Section 5 of the Information Technology Act, 2000 provides that where a law requires a signature, that requirement “shall be deemed to have been satisfied, if such information or matter is authenticated by means of electronic signature affixed in such manner as may be prescribed by the Central Government”. So a properly affixed signature satisfies the signature requirement. Whether the document itself is binding depends on its contents and on the signer's authority, which the signature does not establish.
Through the Certificate Revocation List published by the Certifying Authority that issued it. The Government of India guidelines state that “before relying on a signature the CRL should also be checked to ensure that the corresponding DSC has not been revoked”. Good verification software does this for you; a plain PDF viewer does not.
No. Opening it in Files, Mail or Safari displays the document without validating the signature. Google's guidance for its own India invoices says that viewers such as Apple's Preview and Chrome's PDF Viewer cannot be used to validate a digital signature. You need software built for it, on the phone or on a desktop.
Not by itself. A signature made while the certificate was valid does not become invalid because the certificate later expired. The difficulty is practical: verifying it later needs the issuer certificates and revocation lists as they were on the signing date. That is why the CCA recommends a long term archival signature format for documents that must be relied on far into the future, and why you should save the verification report when you first receive a document.
Class 3 is the standard for signing certificates in current use, and it is what you will normally see on documents issued by public authorities and on corporate filings. What matters more for your purposes is not the label but the chain: the certificate must trace up through a licensed Certifying Authority to the Root Certifying Authority of India.
That is a real discrepancy and worth pursuing. The signature is cryptographically fine, but the person who signed is not the person the document says issued it. It may be an authorised delegation, or it may not. Ask the public authority in writing who was authorised to issue the order on that date, and for the office order that authorised them. That is an RTI request for an existing record, which is exactly what the Act reaches.
You cannot ask a public authority to give an opinion on genuineness, because the RTI Act gives access to records, not answers. But you can ask for the record itself: a copy of the order as issued, the despatch register entry, the file noting approving it, or the list of officers authorised to sign. Comparing that against the document in your hand answers the question.