Credential Install Not Recorded For The Current Declaration

URI: https://docs.ankatech.co/errors/host-credential-install-declaration-mismatch
HTTP Status: 409 Conflict

When you see this

The environment host reported, through POST /api/v3/admin/platform/setup/backend/host-credential-install, that it installed this deployment's PKCS#11 partition credential with outcome INSTALLED — and the report named a backend (backendToken) that the deployment's committed declaration does not name. The deployment was re-declared as another backend, or its declaration was withdrawn, after the host was invoked.

The install did happen on the host, so the report is audited, with the backend it named and a field saying the install was not recorded against the declaration. What did not happen is the stamp: the host keeps every appliance's partition credential in one per-environment secret, so an install for one backend says nothing about a different one. The setup status therefore keeps asking for the partition credential, and the activation it offers still carries the credential argument.

This is a 409 rather than a success because the request conflicts with the current state of the deployment and is resolved by acting on that state (RFC 9110 §15.5.10). A 2xx would let a host that checks only for success believe the deployment had moved on when it has not.

Common Causes

• The declaration was changed on the HSM / Cloud KMS screen while an activation with --pkcs11-pin-file was running on the host for the previously declared appliance.
• The declaration was withdrawn, and the host activation was run from a terminal prepared before the withdrawal.
• The host was invoked for the wrong appliance: the partition credential proven and installed belongs to a backend this deployment does not declare.

Response Example

{
  "type": "https://docs.ankatech.co/errors/host-credential-install-declaration-mismatch",
  "title": "Credential Install Not Recorded For The Current Declaration",
  "status": 409,
  "detail": "The host reported a PKCS#11 partition credential install for 'cloudhsm', but this deployment's committed declaration does not name that backend. The report is audited; it is not recorded as the current declaration's credential install, so the setup status still asks for the partition credential. Install the credential for the backend the deployment now declares.",
  "instance": "/api/v3/admin/platform/setup/backend/host-credential-install",
  "timestamp": 1787494020,
  "extensions": {
    "requestId": "c41f8e2a-6b07-4d93-a5e8-2f1b9d7c3e60"
  }
}

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

The detail names the backend the report was for, in its canonical lowercase form rather than as submitted, and carries no credential, no digest of one and no secret name.

What this refusal leaves behind. The host-side install is complete: the partition credential is in the environment's secret and its disaster-recovery copy, and the operator's intake file has been shredded. Nothing was bound: the host activation stops on this answer before it attempts the bind (init-hsm.sh exits 4), so no key-encryption key was created and no bind was recorded.

How to Resolve

1. Confirm what the deployment declares today with GET /api/v3/admin/platform/setup/status (declaredBackend), or on the Cryptography & Trust → HSM / Cloud KMS screen.
2. If the declaration is the backend you intend to use, run the host activation again with the partition credential for that backend — the command the screen shows, which still carries the credential argument.
3. If the declaration is wrong, correct it first — re-declare the intended backend, which is possible until the deployment is bound — and then run the activation the screen shows for it.

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