> ## Documentation Index
> Fetch the complete documentation index at: https://docs.knoxcall.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Migration Signing Key

> The RSA private key KnoxCall signs Workload Identity Federation assertions with during cross-cloud secret-store migrations — generate it, base64-encode the PEM, store it, and restart the API workers.

# Migration Signing Key

During a [secret-store migration](/essentials/migrations/overview) 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

```bash theme={"dark"}
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out migration-signing.pem
base64 -w0 migration-signing.pem     # macOS: base64 -i migration-signing.pem | tr -d '\n'
```

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*:

| Field                        | Value                         |
| ---------------------------- | ----------------------------- |
| **Signing key (base64 PEM)** | The single-line base64 output |

**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.

## Related

* [Secret store migrations](/essentials/migrations/overview)