Key Management

ChainLaunch manages cryptographic keys for all blockchain nodes — identity keys, TLS certificates, and CA keys. Keys are encrypted at rest and only decrypted in memory when needed.

Key Types

Key Providers

ChainLaunch supports multiple key storage backends:

View Keys

Via UI

1. Go to Keys in the left sidebar
2. Browse keys by organization or node
3. Click a key to see its details (public key, certificate, expiry)

Via CLI

# List all identities (keys) for an organization
chainlaunch keys list --org Org1MSP
 
# Filter by identity type (admin / client / peer)
chainlaunch keys list --org Org1MSP --type client
 
# Get a specific key by ID
chainlaunch keys get {keyId}

Create Keys

Keys are created automatically when you create organizations and nodes. To create a key manually:

Via CLI

chainlaunch keys create \
  --name custom-signing-key \
  --algorithm EC \
  --curve P-256

Supported algorithms:

• ECDSA with curves P-256 or P-384
• Ed25519

Export a Certificate

The certificate (and CA certificate, when present) are returned as part of chainlaunch keys get. Pull just the PEM with jq:

chainlaunch keys get {keyId} | jq -r '.certificate' > node-cert.pem

Org-level CA certs are exposed through the organization, not the key. See chainlaunch fabric org list for the org's signCertificate and tlsCertificate.

Key Rotation

ChainLaunch does not expose a separate "rotate" endpoint today. To rotate, generate a new key and reconfigure the consuming node:

# Generate a replacement key
chainlaunch keys create --name node-tls-2026 --algorithm EC --curve P-256
 
# Update the node to reference the new key (specifics depend on node type)
# For a Fabric peer this means updating its --tls-key-id / --sign-key-id
# and restarting it; see node-specific docs.

For automatic rotation against an HSM, configure the rotation policy on the underlying provider (Vault pki engine, AWS KMS auto-rotation) — ChainLaunch consumes the rotated key automatically.

Certificate Renewal

# Check certificate expiry
chainlaunch keys get {keyId} | jq -r '.expiresAt'
 
# Renew the certificate (re-uses the existing keypair, new validity)
chainlaunch keys renew-cert {keyId} --cn "peer0.org1.example.com" \
  --valid-for 8760h \
  --dns peer0.org1.example.com

Configure Key Providers

Database Provider (Default)

No configuration needed — active by default. Keys are encrypted with AES-256 using PBKDF2 key derivation with unique salts per key.

The encryption key is derived from KEY_ENCRYPTION_KEY environment variable (auto-generated if not set).

HashiCorp Vault (Pro)

# Set Vault connection
export VAULT_ADDR=https://vault.yourcompany.com:8200
export VAULT_TOKEN=hvs.xxxxx
 
# Create a Vault key provider
curl -X POST http://localhost:8100/api/v1/key-providers \
  -H "Content-Type: application/json" \
  -d '{
    "name": "vault-production",
    "type": "VAULT",
    "config": {
      "address": "https://vault.yourcompany.com:8200",
      "token": "hvs.xxxxx",
      "transitPath": "transit",
      "kvPath": "secret/chainlaunch"
    }
  }'

Vault requirements:

• Transit secrets engine enabled
• KV v2 secrets engine enabled
• Policy with create, read, update on transit and KV paths

AWS KMS (Pro)

curl -X POST http://localhost:8100/api/v1/key-providers \
  -H "Content-Type: application/json" \
  -d '{
    "name": "aws-production",
    "type": "AWS_KMS",
    "config": {
      "region": "us-east-1",
      "accessKeyId": "AKIA...",
      "secretAccessKey": "...",
      "kmsKeyId": "arn:aws:kms:us-east-1:123456:key/xxx"
    }
  }'

Authentication modes:

• Static credentials — access key + secret key
• Instance role / IRSA — for EC2 or EKS deployments
• Named profile — for SSO/assumed role setups
• STS role assumption — cross-account access

Security Best Practices

1. Use Vault or KMS in production — the database provider is fine for dev but enterprise deployments should use a dedicated key management system
2. Rotate keys regularly — at least every 90 days for compliance
3. Back up the encryption key — if you lose KEY_ENCRYPTION_KEY, you cannot decrypt database-stored keys
4. Restrict API access — use RBAC to limit who can view or export keys
5. Monitor key operations — enable audit logging to track all key access

Next Steps

• Security Best Practices for comprehensive security guidance
• RBAC & Permissions to restrict key access
• Backups to back up key material
• Terraform Provider to manage key providers as code