Send RFC 3161 Timestamp Requests with tsget

tsget sends an RFC 3161 timestamp request and saves the reply, the proof-of-existence step behind trusted timestamping. This guide covers creating the request, sending it over HTTP and HTTPS, and saving the binary reply for later verification. Allow about fifteen minutes, plus whatever time your timestamp service takes to issue credentials or publish its URL.

The local manpage comes from the OpenSSL 3.0.13 package. The installed OpenSSL executable here reports 3.6.4, but tsget is not on this machine's PATH. That distinction matters: the workflow and option contract below are from tsget(1ssl), while the request-generation checks use the available openssl ts command. Confirm the command on the host where you will run it.

You need a shell, an input file, a timestamp service URL, and either a CA bundle file or a prepared CA directory for HTTPS. You do not normally need elevated privileges. Keep the original data and request files; timestamp replies are evidence and should not be casually replaced.

1. Check which OpenSSL tools are available

Start with read-only checks. They do not need sudo:

$ command -v openssl
/usr/bin/openssl
$ openssl version
OpenSSL 3.6.4 25 Aug 2026 (Library: OpenSSL 3.6.4 25 Aug 2026)
$ command -v tsget
tsget not found

Your output may differ. If tsget is missing, stop before attempting a request. Install or enable the package component that supplies the script through your normal system-management process, then rerun command -v tsget. Do not replace it with an invented wrapper: the HTTPS and output behaviour described here belongs to the OpenSSL client.

Checkpoint: on the target host, both openssl and tsget should resolve to the binaries you intend to use. The manpage header identifies the reference documentation as OpenSSL 3.0.13, so read the local manpage again if your package has a different release.

2. Create the timestamp request

tsget sends requests; it does not create them or verify replies. Use openssl ts -query for those separate jobs. For a small test, create or choose a file that must remain unchanged:

$ printf '%s\n' 'data to timestamp' > input.txt
$ openssl ts -query -data input.txt -cert -out input.tsq
Using configuration from /etc/ssl/openssl.cnf
$ file input.tsq
input.tsq: data

The exact configuration path and file description vary. A non-empty request file is the useful check. -cert asks for the timestamp authority's certificate to be included in the eventual response. It does not authenticate the HTTP connection and does not make an untrusted service trustworthy.

If the input is sensitive, remember that the request contains a digest of it, not the original bytes. That digest can still disclose that two parties timestamped identical content. Treat the request and reply according to your evidence-handling policy.

3. Send one request over HTTP

Replace the example URL with the path published by your timestamp authority. This ordinary command writes the reply beside the request, changing only the new output file:

$ tsget -h http://tsa.example.invalid/tsa input.tsq
$ ls -l input.tsr
-rw-r--r-- 1 user user 1234 Sep 27 15:20 input.tsr

The output size and timestamp are examples, not promises. With no -o, tsget derives the output name from the input name and uses the .tsr extension. A successful transfer is not the same as a valid timestamp. Keep the reply and verify it with openssl ts -verify once you have the authority's certificate chain and the original data.

HTTP provides no transport confidentiality or peer authentication. Use it only when the service explicitly permits it and the surrounding network is trusted. For normal production use, prefer HTTPS.

4. Send one request over HTTPS

For HTTPS, supply trust material with -C or -P. The peer certificate chain must lead to a CA in that file or directory:

$ tsget -h https://tsa.example/tsa -C /path/to/ca-bundle.pem \
    -o input.tsr input.tsq
$ test -s input.tsr && echo 'reply file is non-empty'
reply file is non-empty

-C names a PEM CA store. If you use -P /path/to/ca-directory instead, the directory must already be prepared with openssl-rehash. That preparation changes the CA directory, so do it during your normal certificate-store maintenance and review the resulting links. Do not point -P at an arbitrary directory of certificates.

The -o option is valid here because there is exactly one request. It gives an explicit destination, which is easier to audit in a script. Do not choose an existing evidence file blindly: an output path can overwrite it. Pick a new name, or make a reviewed backup before running the command.

5. Use client certificate authentication only when required

Some timestamp services require the caller to authenticate with an X.509 certificate. Pass the matching private key and certificate together:

$ tsget -h https://tsa.example/tsa -C /path/to/ca-bundle.pem \
    -k /path/to/client_key.pem -c /path/to/client_cert.pem \
    -o input.tsr input.tsq
Enter PEM pass phrase:

With a passphrase-protected key, omitting -p makes tsget prompt. That is preferable to putting a secret in shell history or a process list. The -p option supplies the passphrase directly, so use it only when a protected secret-handling mechanism makes that exposure acceptable. Do not paste a private key or passphrase into a ticket, terminal recording or article.

The -k and -c options are a pair. The key is not a replacement for the CA trust store: you still need -C or -P to verify the server certificate. File permissions for private keys are an operational control; inspect them with ls -l and follow your service's policy rather than changing them with a blind recursive command.

6. Send several requests and inspect progress

Give several request files on one command line when the service accepts them:

$ tsget -h https://tsa.example/tsa -C /path/to/ca-bundle.pem \
    -v -e .reply input-one.tsq input-two.tsq
input-one.tsq
input-two.tsq
$ ls -l input-one.reply input-two.reply

-v prints the name currently being processed on standard error. Without -o, each output keeps its input base name and receives .tsr, or the extension supplied by -e. Do not combine multiple requests with -o; the manpage permits that option only for one request.

More than one request can be sent without closing the TCP connection. That is a transport optimisation, not a guarantee that the service will issue every reply. Check every output and record the command status in your automation.

7. Diagnose failures without weakening trust

For a connection problem, first rerun with -d to enable verbose diagnostics from the underlying Curl module:

$ tsget -d -h https://tsa.example/tsa -C /path/to/ca-bundle.pem \
    -o input.tsr input.tsq
$ printf 'exit status: %s\n' "$?"
exit status: 1

The exact diagnostic and status depend on the failure. Check the URL path, DNS, proxy policy, server availability and CA file. A certificate error is not a prompt to remove -C, disable verification or switch to HTTP. Fix the trust configuration or ask the service operator for the correct CA chain.

If the request is rejected, confirm that it was generated by openssl ts -query, that the service expects RFC 3161 requests, and that any required policy or client certificate is present. tsget stores the timestamp response without interpreting it, so use openssl ts -verify with the original data and trusted TSA certificates for a meaningful validation step.

There is no persistent undo operation in these examples. To recover from a mistaken output path, stop using the file, preserve it for review, and rerun with a new destination. Do not delete a response merely because it failed verification until your evidence policy allows that deletion.

Done means