Timestamps and trust
What "trusted" means, who decides it — and why a timestamp rescues an expired signature.
A verification result has two layers that are easily confused.
Structurally valid means: signature and record are intact, the file was not altered after signing. A self-signed manifest satisfies that too.
Trusted means, in addition: the signer's certificate chains back to an anchor on the official C2PA list.
The signed-in product speaks German, so its messages are quoted in German throughout, with the English rendering in italics.
The two layers do not affect each other
Where the trust check could not run, the result stays at "not trusted" — the structural statement is untouched by that.
Conversely, neither an expired certificate nor a missing timestamp makes an intact file "invalid".
What the timestamp is for
Signing certificates expire — often after a few years. Without a timestamp every file signed with one would stop being trusted afterwards, even though everything was in order at the time of signing.
The timestamp attests when the signing happened, placing the signature back inside its certificate's validity window. A third-party file with a long expired certificate therefore still reads as valid and trusted.
Where it is missing, the verify page says:
Der Signierzeitpunkt stammt aus keiner vertrauenswürdigen Quelle. Wann signiert wurde, ist damit nicht belegt.
The signing time comes from no trusted source. When the signing happened is therefore not evidenced.
The provenance chain then reads „ohne Zeitstempel“ (without timestamp).
What leaves the product when signing
Signing and timestamping transmit only a checksum of the file. The image data itself does not leave verstag.
The timestamp is issued by SSL.com's official C2PA timestamp authority.
When the timestamp authority fails
Where the timestamp authority is unreachable, the signature fails and the job is completed as failed — for image and video alike. You read a general refusal, not a technical message.
The failed attempt does not vanish, though: it sits in the Content Credentials record as event „Signiert“ (signed) with outcome „Fehler“ (error).
Where the signature succeeds, the trust verdict on the fresh manifest sits in the same record; it is readable in the export's detail column, the certificate number in a column of its own.
Where you see the findings
On the „Prüfen“ page. There the box „Vertrauensprüfung“ (trust check) appears — and only where there is a notable finding. Counted as unremarkable are a trusted signing credential and an attested timestamp; a file signed without a timestamp therefore does not count as unremarkable.
The box distinguishes two axes: „Warnung“ (warning) where the file itself is affected, and „Manuelle Prüfung“ (manual check) where the check did not happen. Where both apply, the box carries the warning. Where the check reports an unknown status, that is displayed too; the raw value sits under „Technische Details“.
The library does not have these sentences. There the verdict is reduced to three outcomes:
| Marker | Meaning |
|---|---|
| „Content Credentials geprüft“ · seal „Verifiziert“ | valid and on the official list |
| „Signiert · Aussteller unbekannt“ · seal „Nicht vertrauenswürdig“ | valid, but not on the list |
| „Ohne Content Credentials“ · seal „Ohne Nachweis“ | everything else |
Two times not to confuse
„Signiert“ on an output in the library is the clock at the time of the render run.
The time in the provenance chain comes from the manifest itself.
The two can differ, and neither is automatically the attested time from the timestamp.
Conformance, not certification
verstag is listed as conformant on the C2PA Conforming Products List. Certification would mean assessment by a third party; there is none here.