Blog Details

Introduction

Producing a signed, time-stamped evidence certificate is only half the job. The other half is being able to verify it — to prove, on demand, that the signature is genuine, that the document hasn't changed since signing, and that the timestamp really belongs to this certificate. If verification depends on uploading the file to some website or on having the right copy of Adobe handy, you have a problem the day you're in a courtroom or on an air-gapped network. This article explains how e-Dex verifies a certificate completely offline.

Why Verification Matters as Much as Signing

A certificate that no one can independently check is just a PDF. Opposing counsel may challenge it, a judge may ask how you know it's authentic, and months later you yourself may need to confirm the file in your archive is the one you produced. Verification turns a claim ("this is signed and timestamped") into a demonstrable fact. The stronger and more self-contained that check is, the more weight the certificate carries.

Three Things e-Dex Checks

e-Dex's built-in viewer opens a certificate PDF and its timestamp file and reports three independent proofs in plain language: the digital signature, the trusted timestamp, and the binding between the timestamp and the exact certificate in front of you. Each gets a clear green / amber / red verdict so you don't have to interpret cryptographic jargon.

1. The PAdES Digital Signature

A PAdES signature (PDF Advanced Electronic Signatures) embeds a cryptographic signature inside the PDF, made with the signer's Digital Signature Certificate. e-Dex checks that the signed content still matches — confirming the document has not been modified since signing — and shows the signer's name and certificate details. Change a single byte after signing and the check fails, which is exactly what you want.

2. The RFC-3161 Trusted Timestamp

An RFC-3161 timestamp is a token issued by a Time-Stamping Authority (TSA) that seals the precise time a document existed. e-Dex verifies the TSA's own signature over the token — proving the timestamp itself wasn't forged — and displays the sealed time in both UTC and IST, along with the TSA's identity, policy and serial. It's independent proof of when, not just what.

3. Binding: Does the Timestamp Seal THIS Certificate?

This is the subtle, important one. A valid timestamp from a real TSA still has to belong to the certificate you're holding. e-Dex confirms the binding by comparing the digest sealed inside the token against the integrity hash printed on the certificate. If they match, the timestamp provably seals this exact document; if they don't, the viewer says so. Without that check, a genuine timestamp could be waved over the wrong file.

Doing It Entirely Offline

Crucially, all three checks run on your machine, with no internet and no Adobe. That matters for forensic work: evidence is often handled on isolated or air-gapped systems, and uploading a certificate to a third-party verifier is exactly what you don't want to do. With e-Dex the certificate proves itself, anywhere.

A Word on Trust Anchors

e-Dex also reports, for information, whether the TSA's certificate chains to a root your system already trusts. A free or self-hosted TSA (such as FreeTSA) still produces a perfectly valid, integrity-checked timestamp — it simply won't chain to a public commercial root, and e-Dex labels that honestly rather than failing it. For the strongest "trusted by default" story, use a commercial TSA; either way, the token integrity and binding are what prove the seal.

Conclusion

A certificate is only as good as your ability to verify it. By checking the signature, the timestamp and the binding — offline, in plain language — e-Dex — the Digital Evidence Integrity Suite lets a Section 63 / 65B certificate prove its own authenticity on any machine, with no dependence on the cloud or third-party tools. That self-contained verifiability is what makes digital evidence genuinely defensible.