RFC 3161 structure
That the file is a time-stamp response (TimeStampResp) or a CMS token, and that the authority granted it.
Timestamp validator (.tsr)
Check a qualified (eIDAS) timestamp and the file it binds.
Drag the original file and the timestamp (.tsr or .tst) that came with it. The file never leaves your browser: its fingerprint is computed here and only the fingerprint and the timestamp are sent. We tell you, point by point, what holds and what does not.
What it checks
Seven checks, each with its own answer.
A timestamp can be valid and not belong to your file; it can bind your file and come from an authority on no list at all. So we never give one “valid”: we give each answer on its own.
File fingerprint
That the SHA-256 fingerprint inside the timestamp is exactly the fingerprint of the file you added. One different byte and it does not match.
Signature and attributes
That the signed attributes are the ones the standard requires (content type, digest of the timestamp, ESS certificate identifier) and that the CMS signature is valid.
Signing certificate
That it was valid at the time of the timestamp and is authorised for time stamping.
EU trusted list
That the certificate belongs to a qualified time-stamping service (QTST) with granted status, according to a dated copy of the list.
Chain and revocation
The chain is checked as far as it travels inside the timestamp. Revocation is not queried, and the page says so.
.tsr and .tst
Why other validators reject your .tsr
A .tsr is the authority’s complete response (RFC 3161): a status plus the token. Many web validators only read the CMS token, the .tst, and fail on the nine status bytes in front of it. The timestamp is not the problem.
Both work here
Upload the .tsr as you received it or the extracted .tst: the result is the same.
With OpenSSL
openssl ts -verify -in timestamp.tsr -data file -CAfile autoridad-sellado.pem -partial_chain. The authority’s certificate is a leaf, not a CA: without -partial_chain OpenSSL looks for its issuer and fails.
If the timestamp is Sellat’s
The certificate page offers the .tsr, the .tst and the authority’s certificate. The evidence package carries all three.
Frequently asked questions
Before you ask.
What is a .tsr file?
The response of a time-stamping authority under RFC 3161: it carries the status of the request and, when granted, the signed token with your file’s fingerprint, the time and the authority’s certificate.
Do I need to upload the original file?
Yes, to check that the timestamp binds that file. The file never leaves your browser: its SHA-256 fingerprint is computed on your device and only the fingerprint and the timestamp are sent. Without a file, the validator judges the timestamp alone.
Does it work for timestamps that are not Sellat’s?
Yes. Any .tsr or .tst from a provider on the EU trusted list validates the same way; the FNMT-RCM is one of them. A timestamp from an authority not on the list is read and verified, but not called qualified.
Why does my usual validator say the file is invalid?
Almost always because it expects the CMS token (.tst) and receives the complete response (.tsr). Both are accepted here, and Sellat’s certificate page also offers the .tst.
What does “revocation not checked” mean?
That we have not asked the authority whether the signing certificate was revoked. The other checks do not depend on it, but a complete validation includes it; the certificate names its OCSP and CRL.
No timestamp yet?
Protect a file with Sellat and add a qualified timestamp issued by the FNMT-RCM. Download it from the certificate and verify it here.
Protect a file