Don't Trust Us — Verify It Yourself. Your Timestamp Checks Out Without Audiverify.

Here is a fair question anyone evaluating a documentation service should ask: what happens to my record if your company disappears? If the only way to check a certificate is to visit the issuer's website, then the evidence is only as durable as that company's hosting bill. That is a real weakness, and it applies to a lot of services in this category.

So rather than asking you to take our word for it, we ship the means to check it without us. Every evidence pack now contains the raw RFC 3161 timestamp token issued by Sectigo, plus a VERIFY.txt with the exact commands to verify it. No Audiverify account. No API call to our servers. Just OpenSSL, which ships on macOS and Linux and is available on Windows.

Below is a genuine verification of a real certificate, run exactly as the instructions say. The output is unedited.

What is actually in the pack

Download the evidence pack for any certificate and you get, among other files:

• timestamp-token.tsr — the TSA's signed timestamp token, in binary DER form. This is the actual cryptographic artifact, not a screenshot or a PDF claim about it.
• VERIFY.txt — the commands, the certificate's SHA-256 fingerprint pre-filled, and a plain statement of what the timestamp does and does not show.
• certificate-data.json — a machine-readable summary, including the TSA's signed time.
• audit-log.txt — the recorded history of the certificate.

Step 1: read the token

The first command reads what the Time Stamping Authority actually signed:

openssl ts -reply -in timestamp-token.tsr -text

On a real certificate (AUD-2026-DBHPPSAG), that prints:

Status info:
Status: Granted.
Policy OID: 1.3.6.1.4.1.6449.2.1.1
Hash Algorithm: sha256
Time stamp: Jul 13 18:32:24 2026 GMT
TSA: DirName:/C=GB/ST=Greater London/O=Sectigo Limited/
     CN=Sectigo Public Time Stamping Signer R37

Read that carefully, because none of it comes from us. "Status: Granted" is the TSA confirming it issued the token. The signed time is the TSA's clock, not our server's. The TSA line names Sectigo's own signing certificate. Our infrastructure plays no part in producing this output.

Step 2: confirm it covers your file

A timestamp is only meaningful if it is bound to your specific file. So compute the fingerprint of your audio and check it matches the hash inside the token:

shasum -a 256 your-audio-file.wav          # macOS / Linux
certutil -hashfile your-audio-file.wav SHA256   # Windows

If a single byte of the audio changed after the timestamp was issued, this fingerprint no longer matches — which is the point. The token attests to one exact version of one exact file.

Step 3: verify the signature cryptographically

This is the step that matters most. It checks Sectigo's signature against Sectigo's certificate chain, and confirms the token really covers your fingerprint:

openssl ts -verify -in timestamp-token.tsr \
  -digest 59cfde6839a2f483fbb1f5509e277b0ff54dfcc4f7c40e36293da71c0b2d82b9 \
  -CAfile /etc/ssl/certs/ca-certificates.crt

Result:

Verification: OK

Two things are worth pointing out. First, the fingerprint is already filled in for you in VERIFY.txt — you are not hunting for a value to paste. Second, this works with an ordinary system trust store because the TSA's signing certificate is embedded in the token itself. We request that embedding deliberately when the timestamp is created; without it, independent verification would be far harder. That single flag is the difference between evidence you can check and evidence you have to trust.

The test that is supposed to fail

"Verification: OK" on its own does not tell you much. A check that always passes is worthless — so verify the verifier. Run the same command with a deliberately wrong fingerprint and it must fail:

openssl ts -verify -in timestamp-token.tsr \
  -digest 0000000000000000000000000000000000000000000000000000000000000000 \
  -CAfile /etc/ssl/certs/ca-certificates.crt

error:17800067:time stamp routines:ts_check_imprints:
  message imprint mismatch
Verification: FAILED

That failure is the reassuring part. It proves the check is genuinely comparing your fingerprint against what the TSA signed, and that "OK" earlier was a real result rather than a formality. We recommend running this negative control yourself. Any verification you cannot make fail on purpose is not a verification.

What this proves — and what it does not

Being precise here matters more than sounding impressive. What the token establishes is narrow but solid: this exact fingerprint was submitted to an independent Time Stamping Authority at or before the signed time, and that authority — not Audiverify — attested to that time.

What it does not establish: who created the work, who owns it, whether it is original, or whether it may be distributed. Those are separate determinations, and a timestamp does not make them. Anyone claiming a timestamp proves authorship is overselling it. Ours documents when a file existed, with a third party vouching for the clock.

One more honest note on scope: the RFC 3161 timestamp is applied to the SHA-256 fingerprint of your audio file. Your declarations — AI involvement, AI-training terms, contributors — are recorded on that same dated certificate alongside it, but they are not themselves signed by the timestamp authority.

Why we built it this way

Because the alternative is asking you to trust a small company indefinitely, and that is not a reasonable thing to ask. Motiva LTD is a UK company with a real registration number, but no startup can promise it will exist in twenty years. Evidence that depends on our continued existence is weaker evidence.

A token signed by an established Time Stamping Authority, verifiable with standard open-source tools against publicly published certificates, does not have that dependency. If Audiverify vanished tomorrow, the pack you already downloaded would verify exactly the same way — the commands above never touch our servers.

That is the useful version of "independent". Not a badge on a page, but a file you hold and can check yourself, today, with a command you can copy.

Try it on your own certificate

Open any certificate in your dashboard and download the evidence pack. Run the three commands in VERIFY.txt, then run the negative control. If anything does not behave as described here, tell us — a verification guide that does not work is worse than none, because it makes real evidence look fake.

Related reading

• How Audiverify works
• How to document when a song was created
• Audio fingerprinting, explained
• Copyright vs documentation — what each one does

Audiverify issues timestamped documentation for music releases. Timestamps are issued by Sectigo under RFC 3161 and can be verified independently, without Audiverify. This article is general information, not legal advice.