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 resolves to
REQUIREDbut no time-stamping authority connection is configured for the deployment. - The policy is
REQUIREDand the authority is configured but unreachable, or the request to it was interrupted. - 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, or carries no signer certificate — see the platform's TSA trust anchors.
- The configured endpoint is rejected before the call: it does not use HTTPS, has no host, cannot be resolved, or resolves to a non-routable address.
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
- Check that the deployment has a time-stamping authority connection configured, and that its endpoint is an HTTPS URL with a resolvable, routable host.
- Confirm at least one TSA trust anchor is
ACTIVEunder/api/v3/admin/platform/tsa/trust-anchors. A retirement that emptied the active set is a common cause of tokens failing trust validation. - Verify the authority itself is reachable and answering; an unreachable or unhealthy authority produces this refusal for every
REQUIREDtenant. - 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.
- 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.