Trusted timestamps (RFC 3161): prove a file existed at a point in time

A hash shows that a file has not changed. It cannot show when the file existed, because you can compute a hash at any time. A trusted timestamp adds that missing piece: an outside authority signs a statement that a particular hash existed before a particular moment.

This guide is part of our guides to verifying files, images and text. It shows how to request a timestamp with OpenSSL, how to verify it later, and what it can and cannot prove. If you want the everyday version for essays and manuscripts, see our walkthrough on hashing and timestamping your drafts.

What a trusted timestamp is

The standard is RFC 3161, the Time-Stamp Protocol, published by the IETF in 2001. It describes a service that supports "proof that a datum existed before a particular time", run by a time-stamp authority (TSA). You send the TSA a request containing a hash of your file. The TSA returns a signed time-stamp token containing that hash, the time, a serial number and the policy it was issued under.

RFC 3161 sets rules for the TSA. Among them, it must use a trustworthy source of time, include a unique serial number in each token, time-stamp only a hash of the data, not examine that hash beyond checking its length, and not include any identification of the requester in the token. It must also sign tokens with a key reserved for time-stamping.

Because only the hash travels, the TSA learns nothing about your file's contents. Because the token is signed, anyone with the TSA's certificate can check it years later without trusting you.

You need

• The file to timestamp.
• OpenSSL (openssl ts is part of it) and curl. Both come with most Linux distributions.
• The address of an RFC 3161 TSA, plus its CA certificate and TSA certificate for verifying. This guide uses freeTSA.org.

Step 1: Create a request with OpenSSL

The openssl-ts documentation gives the query form. This run adds -sha256 to name the hash algorithm and -cert to ask the TSA to include its certificate in the reply:

openssl ts -query -data draft-2026-10-30.txt -no_nonce -sha256 -cert -out draft.tsq

You can read the request back to see exactly what will be sent:

openssl ts -query -in draft.tsq -text

Version: 1
Hash Algorithm: sha256
Message data:
    0000 - aa 7c 6b 2c 2d 12 31 f3-ee 60 1b a8 c1 57 5b 6e   .|k,-.1..`...W[n
    0010 - d6 70 d3 09 be 24 cc de-40 e1 76 51 c3 f9 36 69   .p...$..@.vQ..6i
Policy OID: unspecified
Nonce: unspecified
Certificate required: yes
Extensions:

The message data is the file's SHA-256, the same value sha256sum prints (aa7c6b2c...c3f93669). Nothing else about the file is in the request.

Step 2: Send it to a TSA

OpenSSL builds and checks requests but does not send them over HTTP, so use curl. The freeTSA.org instructions give this form:

curl -H "Content-Type: application/timestamp-query" --data-binary '@draft.tsq' https://freetsa.org/tsr > draft.tsr

Then read the reply:

openssl ts -reply -in draft.tsr -text

Status info:
Status: Granted.
Status description: unspecified
Failure info: unspecified

TST info:
Version: 1
Policy OID: tsa_policy1
Hash Algorithm: sha256
Message data:
    0000 - aa 7c 6b 2c 2d 12 31 f3-ee 60 1b a8 c1 57 5b 6e   .|k,-.1..`...W[n
    0010 - d6 70 d3 09 be 24 cc de-40 e1 76 51 c3 f9 36 69   .p...$..@.vQ..6i
Serial number: 0x09975AB3
Time stamp: Oct 31 02:42:51 2026 GMT
Accuracy: unspecified
Ordering: yes
Nonce: unspecified
TSA: DirName:/O=Free TSA/OU=TSA/description=This certificate digitally signs documents and time stamp requests made using the freetsa.org online services/CN=www.freetsa.org/emailAddress=busilezas@mailbox.org/L=Wuerzburg/C=DE/ST=Bayern
Extensions:

"Granted" means the TSA issued a token. The message data matches the request, the serial number is unique to this token, and the time is in GMT, so it can fall on a different calendar day from your local clock. Keep draft.tsr with the file; it is the evidence.

Step 3: Verify it later

To verify, you need the token, the file (or the original request) and the TSA's certificates. Download freeTSA's cacert.pem and tsa.crt from its site, then check the token against the file itself:

openssl ts -verify -in draft.tsr -data draft-2026-10-30.txt -CAfile cacert.pem -untrusted tsa.crt

Verification: OK

OpenSSL also printed a warning that tsa.crt "is not a CA cert", which is expected: it is the TSA's signing certificate, passed with -untrusted so OpenSSL can build the chain up to cacert.pem.

Change one line in the file and verify again, and the check fails:

20305FEE6FFA0000:error:17800067:time stamp routines:ts_check_imprints:message imprint mismatch:../crypto/ts/ts_rsp_verify.c:512:
Verification: FAILED

"Message imprint mismatch" means the file's hash is not the hash in the token. The token still proves that the original version existed at that time; it says nothing about the edited one.

Choosing a timestamp authority

Any RFC 3161 TSA works with these commands. What differs is how much weight its tokens carry. Look for an authority that publishes its policy and certificates, states how it keeps time, and has been running long enough that its certificates are likely to stay available.

Free public TSAs are fine for personal records such as draft logs. For contracts, regulated records or anything likely to reach a court, use the TSA your document signing service or certificate provider offers, or one recognised under the rules that apply to you. freeTSA notes that it introduced a new TSA certificate for stamps from 16 March 2026, valid to February 2040, which is a reminder to save the certificates that match each token.

Timestamps also sit inside other formats. The C2PA content credentials standard uses RFC 3161 time-stamps for claim signatures (see the Time Stamps section of the C2PA specification), and signed PDFs can carry one, which our guide to validating a signed PDF shows how to read.

Limits

A trusted timestamp proves that a hash existed before a time. It does not prove who created the file, that the contents are true, or that the file did not exist even earlier. It also depends on the hash algorithm: if SHA-256 were ever broken, old tokens would need fresh stamps with a stronger algorithm.

Keep the pieces together. A token is only useful if you can still verify it later, so store the original file, the request, the reply and the TSA's certificates in one folder, and record which authority you used. If you stamp a manifest of hashes instead of a single file, keep every file listed in the manifest too, since the token can only vouch for files you can still produce.

The evidence ladder for "when"

Sources

1. RFC 3161, Internet X.509 PKI Time-Stamp Protocol (TSP)
2. OpenSSL documentation, openssl-ts
3. freeTSA.org, free RFC 3161 time-stamp authority
4. C2PA Technical Specification 2.5

Questions

• Does the timestamp authority see my file?+

  No. You send only a hash of the file, and RFC 3161 requires the authority to time-stamp only that hash and not to examine it beyond checking its length.

• Is a trusted timestamp legally binding?+

  That depends on the jurisdiction and the authority. Some legal frameworks give extra weight to timestamps from qualified or accredited authorities; a free public authority gives good technical evidence, but check what your court, regulator or institution accepts.

• How long does a timestamp stay valid?+

  As long as its signature can still be checked and its hash algorithm is still trusted. Keep the authority's certificates with the token, and re-stamp important records with a current algorithm if the old one is ever weakened.

• What is the difference between a timestamp and a signature?+

  A signature shows who approved a file; a timestamp shows when the file's hash existed. Many signed documents carry both, so the signing time comes from an outside clock.

• Can I timestamp many files at once?+

  Yes. Hash all the files into one manifest, then timestamp the manifest. The token covers every hash listed in it at that moment.