- Overview
- Tutorials
- How Tos
- Download
- Install
- Configure
- Secure
- TLS API Configuration
- Configure API Authentication and Authorization with JWT
- Configure API Limits
- Set Resource Limits
- Crypto key management
- Restrict key usage
- Namespace Key Management
- Key management service (KMS) configuration
- Optimize
- Observe
- Operate
- Initializing node identity manually
- Canton Console
- Synchronizer connections
- High Availability Usage
- Manage Daml packages and archives
- Participant Node pruning
- Party Management
- Party replication
- Decentralized party overview
- Implementing Multi-Sig in Canton
- Additional Topics
- Managing hosting relationships
- Ledger API User Management
- Node Traffic Management
- Identity Management
- Upgrade
- Decommission
- Recover
- Troubleshoot
- Explanations
- Reference
Migrate to a KMS¶
This section outlines the steps required to migrate from a running non-KMS participant to one that is KMS-enabled, as well as the interoperability between nodes that use KMS and those that do not. The migration procedure depends on the selected mode of operation:
Migrate to encrypted private key storage with a Key Management Service (KMS)
This process requires configuring the node to use a symmetric wrapper key. Migration is done automatically after this configuration step.
Migrate to external key storage with a Key Management Service (KMS) by exporting the key material
This migration consists of exporting the key material (i.e., private and public keys) from the node and directly importing it into the target KMS.
The parties of the original participant and their ACSs are replicated to a new node and configured to use the KMS along with the previously imported key material.
This approach provides a clean and self-contained transition with no namespace change, but it does require participant node operators to have access to the private key material for their keys. This also implies that the private key material must be stored outside of a KMS, which introduces additional security risks related to key custody, storage, and potential exposure.
External parties can be simply replicated on the new Participant, and their owned contracts can be moved without any model-specific transfers, since these parties have their own keys and namespace and do not rely on the Participant’s keys.
For local parties, this approach involves creating a new KMS-enabled Participant and transferring all data (e.g., contracts) from the original Participant. Transferring parties and ownership of all contracts to the new Participant must be done manually through model-specific transfers. This approach can be highly involved and complex, especially if locally hosted parties exist, and it must be adapted case by case depending on the specific contracts and parties owned by the participant. Migrating this way, when locally hosted parties exist, should only be done if exporting the key material is not possible or is deemed insecure.