Skip to content

Key Object Not Resolved

URI: https://docs.ankatech.co/errors/kek-destruction-object-unresolved
HTTP Status: 409 Conflict

When you see this

The key object under a tenant key-encryption key's recorded name is not one the platform can identify as that key, so nothing is destroyed. It is met in two places:

  • At the request. A platform administrator asked to destroy a key whose recorded name is not one the platform gives the tenant's key in its managed tier, so the platform cannot address the key. The request is refused 409, the key keeps its status, and the refusal is recorded in the audit trail as DENIED.
  • When the waiting period ends. In the session that would destroy it, the destruction pass checks that the HSM object under the key's recorded label is the key the platform created, and it was not; or the Cloud KMS key is no longer placed by the tenant's name in its tier's container. Nothing was destroyed, the key is RETIRED again with the refusal reason OBJECT_MISMATCH, a kek-destruction.execution-failed row with outcome FAILURE, stage EXECUTION_REFUSED and this problem type is filed in the audit trail, and the CRITICAL platform alert kek.destruction.object-mismatch is raised and holds until a new destruction of the key is requested. This is not an operational state: something other than the platform placed, replaced or moved an object under the key's name, and the key that wraps the tenant's keys may no longer be the one the platform holds.

A tenant key-encryption key is destroyed at its provider or HSM, never only in the platform's records. A destruction request moves a RETIRED key to PENDING_DESTRUCTION and calls no provider: the platform holds the destruction for the deployment's waiting period (30 days by default), and until it ends a cancel returns the key to RETIRED with no provider call. When the period ends the platform checks the key again and only then asks its provider or HSM to destroy it; the key becomes DESTROYED only once a read of the provider confirms it gone. Until then the destruction can be cancelled while the key object still exists, which returns the key to RETIRED.

Common Causes

  • The HSM holds more than one object under the recorded label, so the platform cannot tell which one to destroy and destroys none.
  • The HSM holds one object under the recorded label, but it carries another identifier than the one recorded, so it is not the key the platform created.
  • The HSM holds no object under the recorded label, but an object under another label carries the recorded identifier (CKA_ID), so the platform cannot tell whether the key was relabelled and destroys nothing.
  • The HSM token is claimed by another environment, so the object on it is not this environment's key.
  • At the request: the key's recorded name is not one the platform gives the tenant's key in its managed tier.
  • The recorded identifier ends in a 0x00 byte. A token may store such an identifier without its trailing zero bytes, so neither a lookup by it nor a comparison is conclusive, and the platform destroys nothing.
  • An HSM token this environment has claimed on which neither the recorded label nor the recorded identifier finds an object is not this refusal: the key is already gone, and the destruction is recorded and then confirmed by the destruction poll.

Response Example

{
  "type": "https://docs.ankatech.co/errors/kek-destruction-object-unresolved",
  "title": "Key Object Not Resolved",
  "status": 409,
  "detail": "The key-encryption key's recorded name is not one the platform gives the tenant's key in its managed tier, so the platform cannot address the key. Nothing was changed.",
  "instance": "/api/v3/admin/platform/tenants/8f14e45f-ceea-467a-9575-0d5b2a1f3c11/key-custody/keks/3c1f7a9e-2b44-4e0d-8f6a-91d2c7b5e0aa/destroy",
  "timestamp": 1793696400,
  "extensions": {
    "requestId": "9c41e7a2-5b08-4d3f-a6e1-2f7c90b4d815"
  }
}

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

How to Resolve

  1. Investigate the HSM token with the vendor's tools: find what changed the object under the key's name, and who changed it.
  2. Do not request the destruction again until the mismatch is explained. Remove a duplicate object outside the platform only once you know which one is the key-encryption key; a new request then starts a new waiting period.

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