How do I prove a document existed on a certain date?

To prove a document existed on a certain date, hash the document and send that hash to a trusted Timestamp Authority, which returns a signed token binding the hash to a time it attests to. That token is evidence a third party can check without trusting you. A date in your own file system, database or document metadata is not evidence, because you control it.

How to prove a document existed on a certain date

The problem with your own dates

Every date you can produce about your own document was produced by you. The file system timestamp, the created-on column in your database, the date printed on page one, the metadata in the PDF: all of them are under the control of the party who wants them believed.

That is not an accusation, it is the structure of the problem. An auditor, a counterparty or a court cannot distinguish an honest date from a convenient one when both come from the same place. Prior art disputes, contract effective dates, notice periods, retention start dates and IP claims all turn on this, and they turn on it years after the fact.

How a trusted timestamp solves it

RFC 3161 describes a small protocol with a large consequence.

Hash the document. A cryptographic hash function produces a fixed-length fingerprint. Any change to the document, even a single byte, produces an entirely different fingerprint.
Send only the hash. The request goes to a Timestamp Authority, a third party that operates a signing service. The document itself never leaves your systems, so this is usable for material you cannot share.
Receive a signed token. The Timestamp Authority returns a token containing your hash and the time, signed with its own key.
Keep the token with the document.

What the token establishes is precise, and worth stating precisely: this exact content existed no later than that moment, and has not changed since. That is a one-sided bound. It proves the document is not newer than the timestamp. It does not prove the document is not older.

Making it still work in ten years

This is the part most implementations skip, and it fails silently.

A timestamp token is verified against the Timestamp Authority’s certificate. Certificates are valid for one to three years. To verify in 2035 a token issued in 2026, a strict verifier needs three things that exist today and will not exist then: the full certificate chain as it was, the revocation status at the time of signing, and an algorithm still considered sound.

So preserve the verification material alongside the token, at the moment you create it. Re-timestamping periodically with a current algorithm, before the previous one weakens, extends the life of the whole chain. Neither can be done retroactively.

Where SealDoc fits

SealDoc requests an RFC 3161 timestamp for every document it processes by default, records a SHA-384 hash chain and a chain-of-custody record, and delivers the result as a PDF/A-3B file, with an evidence pack per document on request. Only the hash is sent to the Timestamp Authority, so the document stays inside European infrastructure.