Skip to content

Time-stamping Authority Unavailable

URI: https://docs.ankatech.co/errors/tsa-unavailable
HTTP Status: 503 Service Unavailable

When you see this

A signing operation could not honour the tenant's RFC 3161 time-stamping policy, and the platform failed closed rather than emitting a signature without the qualified timestamp the policy demands. The refusal is raised at the signing seam, before or instead of producing a signature. The detail names the failure class only — it carries no tenant, policy, or endpoint content, so the response is the same for every caller.

Common Causes

  • The tenant's TSA usage policy is unresolved: every local cache tier and the service-to-service self-heal missed, so the policy cannot be determined and the request is denied rather than silently signed without a stamp.
  • The policy is REQUIRED and the authority is configured but unreachable, or the request to it was interrupted.
  • The authority refused the configured client credential.
  • The authority answered but the answer is unusable: an unexpected HTTP status, an unexpected content type, an empty response, a request it did not grant, or no token.
  • The returned time-stamp token failed trust validation — its signer certificate does not chain to an ACTIVE trust anchor — or carries no signer certificate.
  • The configured endpoint cannot be resolved, or resolves to a non-routable address.
  • The policy is REQUIRED and the tenant's effective connection cannot produce a timestamp at all: it is switched off, its endpoint is not a valid https URL with a host, or the deployment holds no ACTIVE trust anchor. The effective connection is the tenant's own connection override when it has one, and otherwise the deployment connection. The platform refuses every configuration write that would create this state for a tenant that could stamp before it, with 422 tsa-cannot-be-required, so the state arises only after a platform operator acknowledged such a refusal and proceeded — including for a tenant created afterwards that inherits a deployment connection left in that state.

The first six causes are runtime conditions that no configuration check can see, and they remain possible for every REQUIRED tenant whose configuration was admitted. An admitted configuration is one that is not known to fail; it is not a promise that the next signing request will obtain a timestamp.

Response Example

{
  "type": "https://docs.ankatech.co/errors/tsa-unavailable",
  "title": "Time-stamping Authority Unavailable",
  "status": 503,
  "detail": "A required qualified timestamp could not be produced; the signing request is refused",
  "instance": "/api/v3/crypto/sign",
  "correlationId": "550e8400-e29b-41d4-a716-446655440000",
  "timestamp": 1730000000
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details.

How to Resolve

  1. Check the tenant's effective time-stamping connection — its own connection override if it has one, otherwise the deployment connection: it must be enabled, and its endpoint must be an HTTPS URL with a resolvable, routable host.
  2. Confirm at least one TSA trust anchor is ACTIVE under /api/v3/admin/platform/tsa/trust-anchors, and that it is the CA that issued the authority's signing certificate. An ACTIVE anchor that the authority's signer does not chain to fails trust validation exactly as an empty set does.
  3. Verify the authority itself is reachable and answering; an unreachable or unhealthy authority produces this refusal for every REQUIRED tenant.
  4. If the detail reports that the policy could not be resolved, re-check the tenant's TSA usage policy in the admin console so the policy is republished and can be resolved again.
  5. Retry the signing request once the authority and the policy are both in place. Nothing was signed, so there is no partial result to clean up.

For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.