Skip to content

Timestamping (TSA)

What this screen is for

A qualified timestamp is a token an external RFC 3161 time-stamping authority issues over a signature, so that when the signature was made can be proven later by someone who was not there. This screen holds both halves of that arrangement: the connection to the authority — seven configuration values — and the trust anchors, the CA certificates the platform validates the returned tokens against, which are records in their own table rather than values.

Inside the surface, Settings and Trust Anchors are two tabs. Around them the surface carries its own tabs: Configuration, Per tenant, and Activity for a viewer who may read the audit trail.

This screen does not decide whether signatures are stamped. That is a policy, set on Platform Policies and refined per tenant; here you make stamping possible.

What must exist first

  • The permission to read platform configuration, for the connection values, and the permission to read the trust anchors, for the anchor list. The built-in platform administrator, auditor and viewer roles hold both.
  • The permission to write platform configuration to change a connection value, and the third, dangerous permission for the one value that relaxes a guard. Only the built-in platform administrator holds them.
  • The permission to manage trust anchors, to upload, retire or delete one. The administrator holds it; the auditor and viewer roles hold only the read.
  • For the Per tenant tab, the permission to write per-tenant timestamping connection overrides. It is its own permission, not the platform-configuration write: the built-in platform administrator and platform operator hold it, so an operator manages a tenant's override while every connection value on Configuration stays read-only for them. The tab reads a tenant's override only under the matching read permission, which the administrator, operator, auditor and viewer roles all hold; the auditor and viewer roles hold only that read.
  • An authority to point at. The endpoint must be an absolute https:// URL to a routable public host: the platform rejects http, loopback, private and link-local addresses and internal host names at the moment you save.
  • At least one trust anchor before stamping is useful, because a token the platform cannot validate against an anchor is not evidence.

Decisions you make here

The connection

Seven values make up the connection. Enabled is the master switch and is off by default. The endpoint URL addresses the authority. The policy OID is copied verbatim into each request and is left empty unless the authority documents one its subscribers must request — an OID it does not honour makes it answer with a non-granted status and the signing operation fails rather than falling back to an unstamped signature.

The hash algorithm is the hash each request's imprint is built with: SHA-256 (the default), SHA-384 or SHA-512. Choose one the authority supports — it refuses a request built with any other, and the next required signature fails. Where resistance to quantum-assisted attacks is required, the ECCG agreed mechanisms recommend a hash output of at least 384 bits. A change applies to the next stamp; stamped signatures keep theirs, and the audit records the algorithm each request used.

The timeout is one deadline on the whole exchange with the authority — the connection, the handshake and the complete reply, however slowly it arrives — and it also bounds the lookup of the authority's name. It accepts 100 ms to 60 s, defaulting to 5 s.

A reply larger than 1 MiB is refused whatever the timeout; a real one is a few kilobytes. The client credential authenticates to the authority where it requires it; it is write-only, sealed by the platform and never surfaced — and nothing validates it against the authority, so saving it is not proof that it is right.

The seventh is the one classified dangerous: whether a timestamp token whose certificate revocation status could not be determined is admitted. It is off by default, which rejects such a token and fails the signature closed. Turning it on records a token issued under a certificate that may already be revoked as trusted, and the audit trail keeps no marker of the doubt.

Turning stamping on, and the refusal that protects tenants

Turn Enabled on only once the endpoint is configured and proven reachable. As soon as any tenant's stamping mode is required, every sign, re-sign and sign-and-encrypt for that tenant fails closed while the authority cannot be reached — so enabling it against an unreachable authority converts a working signing surface into an outage for those tenants.

The reverse is guarded for you. Switching Enabled off, or resetting a value to something that leaves the connection unable to stamp, is refused while that would leave a tenant, or the deployment default, required to stamp over it. The refusal states how many tenants are affected, and you may proceed anyway by confirming with that count. Changes to the connection apply without a restart.

Trust anchors

The Trust Anchors tab lists every anchor with its status, who uploaded it and when, and a warning chip on an active one inside 30 days of expiry. Adding one is deliberately two steps: you paste or upload a PEM or DER certificate, or a PKCS#12 or JKS file with an optional write-only password, the platform analyses it without side effects, and you choose which of the eligible certificates to commit. Nothing is committed silently, and a certificate whose fingerprint is already stored is refused as a duplicate with the whole upload rejected.

More than one anchor may be active at a time, and that is how a CA rotation is done: overlap the incoming anchor with the outgoing one so validation never has a gap. Retire takes an anchor out of validation and keeps the row; the same refusal as above applies when retiring it would leave a tenant, or the deployment default, required to stamp with nothing left to validate against. Delete is offered only on an already-retired anchor. The anchor's own history is not on this tab — it is the surface's Activity tab, which still answers for an anchor that has since been deleted.

Per tenant

The Per tenant tab replaces the whole connection for one tenant. You choose the tenant from a selector, without impersonating it. A tenant with no override inherits the deployment connection and the panel says so; giving it one reveals the full connection form, and reverting puts it back on the deployment connection. The credential is write-only here too: an existing one shows as unchanged and is never read back, and leaving it blank is how an anonymous authority is configured. The connection is submitted all at once, not field by field.

The tab's controls follow the per-tenant override permission above, not the platform-configuration write.

How it relates to other screens

Whether a tenant must, may or may not stamp is decided on the policy screens, not here — the deployment mode is DISABLED, OPTIONAL or REQUIRED, and only under OPTIONAL does each tenant choose:

The rest of this group, and the map that draws this surface's status beside every other connection:

Where to read more