Skip to main content

​
Migration Signing Key

During a secret-store migration from Azure Key Vault or Google Secret Manager, KnoxCall presents signed assertions to the customer’s cloud for Workload Identity Federation, and publishes the public half at its JWKS endpoint. This card holds the private key. Scope: Global defaults only. There is no provider — you generate the key yourself. It is a signing identity: anyone holding it can mint assertions that federate as your KnoxCall deployment.

​
1. Generate the key

The second command prints the PKCS#8 PEM as a single base64 line.

​
2. Enter it in KnoxCall

Settings → Integrations → Global defaults → Migration signing key → Configure: Save credentials, then delete the local PEM file — the encrypted store is now the copy of record.

​
3. Restart, then verify

The key is read once at startup. Restart the API workers, then fetch the JWKS endpoint: it serves the derived public key once a valid key has loaded.

​
Things that bite

  • Saving a new key does not take effect until the API workers restart.
  • A present-but-unreadable row is logged loudly and then ignored, falling back to MIGRATION_SIGNING_KEY from the environment if set. Check the logs rather than assuming the new key took.
  • Rotating invalidates any assertion a relying party has pinned — coordinate with the migration counterparty before you do.