A trusted timestamp is one of the few things in this field that is genuinely cheap. A third party signs a statement that a particular fingerprint was presented to it at a particular moment, without receiving your document, without being able to read it, and without charging you. The exchange takes about a minute.

The protocol is not the hard part. Custody is. The proof arrives as a small separate file, and a year later that file is the thing people cannot find. This post covers what a timestamping authority is, when reaching for one pays, the whole method including the command that fails in a way that looks like a broken service, which endpoints answer, and the alternative that needs no command line.

A companion post covers who else can hold the record and for how long , and another covers how the dates on a document get changed .

What a Timestamping Authority Is

A timestamping authority is a third party whose entire job is to sign one statement: that it saw a particular fingerprint at a particular moment. It does not receive your document, cannot read it, and takes no position on whether anything in it is true.

The public ones are there largely to serve code signing. DigiCert publishes its own timestamp server for exactly that [1 ], because software has a problem documents do not. A signature made with a certificate that later expires has to stay distinguishable from one applied after the expiry, and a trusted timestamp is how that distinction is kept. Documents ride on infrastructure built for something else, which explains a caution further down.

Start with the hash: a fixed-length fingerprint computed from a file’s exact bytes, where any change produces a different fingerprint. There is a fuller treatment in digital hashing for lawyers .

When You Would Actually Reach for One

An agreement you will need to stand behind years from now. The contract, the lease, the settlement, the board resolution. Almost none will ever be questioned, which is the argument for covering all of them rather than guessing which.

Work whose priority date matters. A design, a manuscript, a source tree, a research notebook, a proposal you sent to a prospect. Anything where “I had this before they did” is a claim you might one day make.

Evidence you gather yourself, before anyone asks for it. Photographs of a condition, screen captures, records you export from a system somebody else runs. The date is worth anchoring precisely because you produced it and you hold it.

Anything you may need to show was in force, or show you handed over. Handbooks, retention schedules, published terms, safety procedures, and any document where what matters later is what you sent rather than what they say they received.

This is the option with the fewest dependencies, which is a different claim from being the best proof.

What the Token Contains, and What It Proves

RFC 3161 defines a request and response protocol between a client and a Time Stamping Authority [2 ]. You send a hash. You do not send the document, and the authority has no way to examine what the hash represents. For privileged material that property is the whole point, because what leaves your machine is a fingerprint rather than the document. Satisfy yourself that a given service actually works that way before you rely on it.

The token that comes back always carries a version, a policy identifier, the fingerprint you submitted and the algorithm used, a serial number, and a generation time in UTC, all covered by the authority’s signature. The authority’s name may appear as an optional field, which the RFC treats as a hint rather than identification. The binding identification is the signing certificate.

What it proves: that a hash matching this exact file was submitted to and signed by that authority no later than the stated time, and that the token has not been altered since. What it does not prove: who authored or possessed the document, that its contents are true, or that anyone did anything on that date.

RFC 5816 updated the signer-certificate identifier used alongside these tokens, and nothing else [3 ].

If you want to try it, here is the whole workflow

If commands are not your thing, skip to the next section; nothing below this line is needed to follow the argument. What you would miss is the explanation of why a good token can fail to verify, which is worth knowing even if you never type any of this.

Create the request, which contains a fingerprint of your document and nothing else:

openssl ts -query -data mydocument.pdf -sha256 -cert -out request.tsq

Against a real agreement, that request file came to 69 bytes. Reading it back showed the version, the algorithm, the 32-byte imprint, a nonce, and a flag asking the authority to include its certificate. No filename, no document, no metadata.

Send it:

curl -H "Content-Type: application/timestamp-query" \
  --data-binary @request.tsq https://freetsa.org/tsr -o response.tsr

Three public authorities answered the same request with HTTP 200: FreeTSA returned 4,642 bytes, DigiCert 6,006, and Sectigo 6,634. Most of that spread is the embedded certificate chain, two certificates from FreeTSA and three each from the other two; count does not explain the 628 bytes between DigiCert and Sectigo. All three tokens were opened and read. Every one carried a policy identifier and a serial number, and not one carried an accuracy. The optional authority-name field came back populated from FreeTSA and Sectigo and literally unspecified from DigiCert, which is the required-versus-optional distinction of RFC 3161 observed rather than read. The whole request was then repeated with a different nonce, and all three answered the same way with new serial numbers. FreeTSA’s signing certificate expires in February 2040, DigiCert’s in November 2037 and Sectigo’s in June 2037, which is the horizon on which the advice about re-timestamping below stops being theoretical.

Verify it:

openssl ts -verify -in response.tsr -queryfile request.tsq -CAfile chain.crt

The trap is in that last command, and it fails in a way that looks like a bad token. Without -CAfile, the FreeTSA token failed with self-signed certificate in certificate chain and the DigiCert token failed with unable to get local issuer certificate. Both verified as soon as a trust source was named, and DigiCert is the sharper case: its root was already installed on the machine, and verification still failed until the store was named. This is documented rather than a quirk. The manual page for openssl-ts says at least one of -CAfile, -CApath or -CAstore must be specified. Measured on OpenSSL 3.0.13.

Which Service, and What It Costs

Several public endpoints answer without an account, and the distinction that matters is what each one publishes and what it commits to.

FreeTSA operates a general-purpose endpoint and publishes its certificate chain [4 ]. Read what it does and does not commit to before you depend on it, and price that answer against what it costs, which is nothing.

DigiCert and Sectigo both run standard servers that are free to query, and both answered ordinary requests in September 2026, which is the measurement above rather than a promise to anyone. The caution is not technical. Whatever either of them runs the service for, it is not a commitment to you. Read the current terms of use yourself before relying on one for documents, and do not read today’s open access as a promise.

Where People Lose the Proof

After the minute is over, the work is small and boring. Most of it is filing. The last of it is a habit, and that is the part good filing cannot cover.

Do not lose the token. It is a separate file. Lose it and you are holding a document with nothing attached to it. Store it beside the document and back it up with the document.

Do not re-save the document. The timestamp covers the exact bytes you hashed and nothing else, so opening the file and saving it breaks the proof even when nothing you can see has changed. Tested on a 763-byte agreement for this post: writing a single metadata field grew it to 4,048 bytes, and a plain rewrite produced 1,313. Both then failed verification with message imprint mismatch, while the untouched original still verified. “It only added a title” and “the bytes are unchanged” are different statements. Acrobat was not used here; both were reproduced with exiftool and qpdf on Linux.

Keep the authority’s certificate chain. Download it at the moment you take the timestamp and store it with the token. Verification needs a trust source named explicitly, and the chain as published at the time is the one that will match.

Take a fresh timestamp before the old one stops being checkable. The act is the one you already know from the token route above: hash the document and the old token together, send that, and keep the new token as a third file. Nothing about the document changes. You do not need a precise deadline to get this right, and that is what a one-minute, no-cost operation buys you: re-stamping early costs nothing at all. What it does need is an occasion, because an undated obligation never gets performed at any price. Two that work: re-stamp whenever you next open the document for some other reason, which is free and needs no reminder, and set one repeating calendar entry five years out for the documents you may never open again. Five years is an arbitrary number chosen to be safe rather than exact, and the repetition is what makes it survive. The outer limit is the expiry of the certificate that signed your token, and for the three services here those expiries fall between June 2037 and February 2040. The reason not to wait for that limit is that a second clock has no date on it at all: a hash algorithm can be retired while every certificate involved is still valid. ETSI’s PAdES standards formalize a version of this inside the PDF itself [5 ], which is a different operation from the detached token described here.

What you keep, and what you ask for

The package handed to an examiner or to counsel in year seven is four items, not one:

  • The exact file, unmodified since it was hashed
  • The timestamp response file
  • The authority’s certificate chain as published at the time
  • A short written note of what was done, with what tool, on what date

Read the list backward and it becomes a request. When a document arrives from somebody else with a timestamp attached, those four items are what to ask for, and the one most often missing is the chain as it stood when the token was made.

A Route With No Command Line

OpenTimestamps is the one option here that needs no command line. The project’s own page offers in-browser stamping and states that the hash is calculated in your browser [6 ], which would preserve the property that makes hash-only submission workable for sensitive material. The same page also describes a document being uploaded. Those two statements do not plainly agree, and anyone handling privileged material should satisfy themselves on that point rather than take this paragraph’s word or the page’s. Behavior observed September 2026.

What the route buys is worth being exact about. OpenTimestamps aggregates many users’ hashes into a tree and writes only the root into a Bitcoin transaction, so it is free and needs no account. What it establishes is strictly an upper bound: the hash existed no later than the anchoring block, and the proof is not usable until the calendar server completes the path. Confirmation runs in hours rather than minutes. That is a different product from the signed token described earlier, not a cheaper version of it.

The Minute Is Not the Hard Part

A timestamp is a minute of work and no money, and the cryptography behind it has been stable for two decades. What it asks of you afterward is small and boring and almost never done: keep four files together, do not re-save the document, and come back before the old token stops being checkable.

Nothing above proves who wrote a document, who held it, or whether a word of it is true. It proves that these exact bytes existed by a stated time, a narrow thing that happens to be the thing most often in dispute. Take the minute on the documents you would hate to be asked about, then treat the token as part of the document rather than as a receipt.

References

Every command in this post was executed and every response measured on 2026-09-16, on OpenSSL 3.0.13. Endpoint availability, token contents and vendor behavior described here were verified in September 2026.

[1] DigiCert, Inc., “RFC 3161 compliant Time Stamp Authority server,” DigiCert Knowledge Base. [Online]. Available: https://knowledge.digicert.com/general-information/rfc3161-compliant-time-stamp-authority-server

[2] Internet Engineering Task Force, “Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP),” RFC 3161. [Online]. Available: https://www.rfc-editor.org/rfc/rfc3161

[3] Internet Engineering Task Force, “ESSCertIDv2 Update for RFC 3161,” RFC 5816. [Online]. Available: https://www.rfc-editor.org/rfc/rfc5816

[4] FreeTSA, “FreeTSA,” freetsa.org. [Online]. Available: https://freetsa.org/index_en.php

[5] European Telecommunications Standards Institute, “Electronic Signatures and Infrastructures (ESI); PAdES digital signatures; Part 1: Building blocks and PAdES baseline signatures,” ETSI EN 319 142-1. [Online]. Available: https://www.etsi.org/deliver/etsi_en/319100_319199/31914201/01.01.01_60/en_31914201v010101p.pdf

[6] OpenTimestamps, “OpenTimestamps: a timestamping proof standard,” opentimestamps.org. [Online]. Available: https://opentimestamps.org/