Skip to content

Key Protection Backend Bind Contradicted

URI: https://docs.ankatech.co/errors/key-protection-backend-bind-contradicted
HTTP Status: 409 Conflict

When you see this

First-run completion was attempted on an environment whose recorded key-material bind is contradicted by the backend itself. The bootstrap key metadata rows record what the activation that wrote them believed — the host activation command on the PKCS#11 path, the in-band console activation on the Cloud KMS path — so they are a claim about the backend rather than proof of it; when the corroborating live key resolve fails, the recorded state says bound while the backend holds nothing. Completion is refused fail-closed and the platform is not marked provisioned. extensions.setupState carries KEY_BACKEND_BIND_CONTRADICTED.

Two operations reach it, and what you do next depends on which one answered.

  • POST /api/v3/admin/platform/setup/complete — the PKCS#11 path, where declaring, the host bind and completion are three separate steps.
  • POST /api/v3/admin/platform/setup/backend/activate — the Cloud KMS families, where activation completes first-run provisioning in the same call. Here the refusal arrives late: the per-tenant key-encryption keys already exist on your cloud account and the declaration is already committed. Nothing is rolled back, and nothing should be — both are correct recorded facts. What did not happen is the flip to provisioned, so the platform stays un-administrable rather than reporting a readiness it does not have. The deployment then reads BOUND_UNREACHABLE, which outranks ACTIVE because a completed provisioning does not make a contradicted backend serviceable.

Common Causes

  • The bootstrap tenant key metadata rows exist but the corresponding keys are absent from the backend — for example the token was reinitialised, replaced or restored from a state that predates activation.
  • The environment was pointed at a different backend instance than the one the host activation provisioned.

An unbound backend does not produce this error: readiness is decoupled from the key-material bind, and a backend that merely cannot be reached yields no evidence and does not trigger the refusal.

Response Example

{
  "type": "https://docs.ankatech.co/errors/key-protection-backend-bind-contradicted",
  "title": "Recorded key protection backend state contradicted",
  "status": 409,
  "detail": "The recorded key-protection backend state is contradicted by the backend itself. This environment cannot be marked ready; repair it from the host and try again.",
  "instance": "/api/v3/admin/platform/setup/complete",
  "timestamp": 1730000000,
  "extensions": {
    "setupState": "KEY_BACKEND_BIND_CONTRADICTED",
    "requestId": "17e6b4c9-8035-42fa-b8d1-6c907e2a4f58"
  }
}

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

How to Resolve

  1. Fix the backend so the bootstrap key-encryption keys resolve. On the PKCS#11 path that is a host repair: re-run the host activation command that provisions them. On the Cloud KMS path the keys already exist on your own account — correct whatever makes them unresolvable (a revoked permission, a disabled or scheduled-for-deletion key, a key ring or region that no longer matches the declared coordinates).
  2. Confirm the environment points at the backend instance the activation provisioned.

  3. Re-run the operation that answered:

    • Cloud KMS — re-run POST /api/v3/admin/platform/setup/backend/activate. This is the prescribed route: the re-run adopts the keys that already exist, commits no second declaration, and completes. It does not provision a second set of keys and does not emit a duplicate completion audit row.
    • PKCS#11 — re-run POST /api/v3/admin/platform/setup/complete after the host repair.

    Retrying without fixing the backend cannot succeed either way: the condition is a durable conflict between recorded and actual state, which is why it is a 409 rather than a 503.

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