Import Legacy Keys to AnkaSecure

Bring your existing RSA/ECDSA keys into AnkaSecure in 5 minutes - keep using them while adding PQC

Quick Start: Import PKCS#12 Key

Estimated time: 5 minutes What you'll achieve: Import RSA certificate from .p12 file, ready to use for encryption Requirements: AnkaSecure API access, existing PKCS#12 keystore (.p12 or .pfx file)

Step 1/3: Prepare your keystore (1 minute)

# Convert your .p12 file to Base64
base64 -i mylegacy.p12 -o mylegacy.b64

# Or in one command:
P12_BASE64=$(base64 -i mylegacy.p12)

✅ Expected: Base64-encoded string (starts with MIIK...)

Step 2/3: Import to AnkaSecure (2 minutes)

curl -X POST https://api.ankatech.co/api/migration/private-keys \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "kid": "my-imported-rsa-key",
    "p12Password": "yourP12Password",
    "p12FileBase64": "'$P12_BASE64'",
    "validationMode": "STRICT"
  }'

✅ Success: You'll receive key details:

{
  "kid": "my-imported-rsa-key",
  "kty": "RSA",
  "alg": "RSA-4096",
  "keyOps": ["sign", "verify", "decrypt", "encrypt"],
  "status": "ACTIVE",
  "expiresAt": "2026-12-31T23:59:59Z",
  "createdAt": "2026-01-07T11:00:00Z"
}

❌ Common error: "Invalid PKCS#12 password" - Double-check password

Step 3/3: Use imported key (2 minutes)

# Encrypt with your imported RSA key (works immediately!)
curl -X POST https://api.ankatech.co/encrypt \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "keyId": "my-imported-rsa-key",
    "plaintext": "Test data encrypted with imported key"
  }'

✅ Success: Encrypted data using your legacy key (now managed by AnkaSecure!)

🎯 What's next? - Upgrade to PQC: Add ML-KEM to your RSA key (zero re-encryption) - Import multiple keys: Bulk import from keystore - Migrate from AWS: AWS KMS to AnkaSecure import

Why Import Legacy Keys?

Preserve Existing Cryptographic Infrastructure

Problem: You have 500 RSA keys in production across legacy systems - Re-generating keys requires re-issuing certificates (CA coordination, weeks/months) - Re-encrypting data requires downtime and risk - Applications hardcoded with existing key IDs

AnkaSecure solution: Import existing keys, keep them working, add PQC layer gradually

Benefits: - ✅ Zero re-keying: Keep existing RSA/ECDSA keys - ✅ Zero re-encryption: Existing encrypted data still decrypts - ✅ Zero downtime: Gradual migration, no "big bang" cutover - ✅ Add PQC gradually: Upgrade imported keys to RSA+ML-KEM composite keys

Consolidate Multi-Cloud Key Management

Scenario: Keys scattered across AWS KMS, Azure Key Vault, on-premise HSMs

Traditional approach (keep keys where they are): - ❌ Multiple APIs to learn (AWS SDK, Azure SDK, PKCS#11) - ❌ Different key formats (JWK, PEM, DER) - ❌ Inconsistent policies (algorithm support varies) - ❌ Vendor lock-in (can't move keys easily)

AnkaSecure approach (consolidate into single platform): - ✅ Import from all sources (AWS, Azure, PKCS#12, X.509) - ✅ Unified API (same SDK works for all keys) - ✅ Consistent policies (81 algorithms supported) - ✅ Portable keys (export anytime, no lock-in)

Example: Import from AWS KMS + Azure:

# Import from AWS KMS (export public key first)
curl -X POST https://api.ankatech.co/migration/import/public-key \
  -d '{"publicKeyPEM":"...from AWS...", "keyId":"aws-key-001"}'

# Import from Azure Key Vault (export as PKCS#12)
curl -X POST https://api.ankatech.co/migration/private-keys \
  -d '{"p12FileBase64":"...from Azure...", "kid":"azure-key-001"}'

Result: Both keys now accessible via AnkaSecure API (unified interface)

Supported Import Formats

PKCS#12 (.p12, .pfx) - Recommended

What it contains: - Private key (RSA, ECDSA, Ed25519) - Certificate chain (leaf → intermediate → root CA) - Metadata (alias, key usage, validity dates)

Common sources: - Windows certificate store exports - Java keystores (converted to PKCS#12) - OpenSSL generated keystores - Legacy CA archives

Example: Export from Windows certificate store:

# Windows: Export certificate with private key
Get-ChildItem -Path Cert:\CurrentUser\My |
  Export-PfxCertificate -FilePath mykey.pfx -Password (ConvertTo-SecureString -String "password" -AsPlainText -Force)

Then import to AnkaSecure (use example from Quick Start above)

X.509 Certificates (.crt, .pem) - Public Keys Only

What it contains: - Public key only (no private key) - Certificate chain - Metadata (subject, issuer, validity)

Use case: Verify signatures from external systems (you don't own private key)

Example: Import external CA certificate:

curl -X POST https://api.ankatech.co/migration/import/certificate \
  -H "Authorization: Bearer $TOKEN" \
  -F "[email protected]" \
  -F "keyId":"external-ca-001"

Operations allowed: Verify only (no signing, you don't have private key)

AWS KMS External Keys - Reference Only

What it is: Reference to key stored in AWS KMS (key never leaves AWS)

How it works: 1. Export public key from AWS KMS 2. Import public key to AnkaSecure 3. Encryption operations call AWS KMS API (via AnkaSecure proxy) 4. Decryption operations call AWS KMS API

Use case: Gradual migration (keep keys in AWS temporarily)

Example:

# Step 1: Export from AWS
aws kms get-public-key --key-id alias/my-key > aws-public.pem

# Step 2: Import to AnkaSecure
curl -X POST https://api.ankatech.co/migration/import/aws-kms \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "awsKeyId": "arn:aws:kms:us-east-1:123456789:key/abc-123",
    "awsRegion": "us-east-1",
    "publicKeyPEM": "'$(cat aws-public.pem)'",
    "kid": "aws-proxy-key-001"
  }'

Note: Requires AWS credentials configured in AnkaSecure (contact support for setup)

Import Validation Pipeline

7-Stage Validation Process

AnkaSecure validates imported keys through 7 stages to ensure security and compliance:

Stage 1: Structure Validation - ✅ Valid PKCS#12 ASN.1 format - ✅ Password correct (if protected) - ✅ Parseable by Bouncy Castle crypto library

Stage 2: Key Extraction - ✅ Private key extractable - ✅ Supported algorithm (RSA, ECDSA, Ed25519, etc.) - ✅ Key size meets minimum (e.g., RSA ≥ 2048 bits)

Stage 3: Certificate Chain Parsing - ✅ Leaf certificate present - ✅ Intermediate certificates (if any) - ✅ Root CA certificate (optional)

Stage 4: Key Binding Verification - ✅ Private key matches certificate public key - ✅ No key mismatch (security critical!)

Stage 5: Temporal Validity - ✅ Certificate not before date < now - ✅ Certificate not after date > now (or IMPORT_ONLY mode)

Stage 6: Trust Anchor Validation (RFC 5280 PKIX) - ✅ Chain verification up to trusted root - ✅ Signature validation for each certificate - ⚠️ Optional: Can skip if importing self-signed certs

Stage 7: Security Analysis - ✅ No weak algorithms (MD5 signatures rejected) - ✅ Adequate key sizes (RSA-1024 rejected) - ⚠️ Expiration warnings (< 90 days remaining)

Result: ACTIVE (all pass) or EXPIRED (temporal issues) or REJECTED (security issues)

Validation Modes

Mode	Behavior	Use Case
STRICT	Reject expired or weak keys	Production (recommended)
IMPORT_ONLY	Allow expired keys, restrict to decrypt/verify only	Migration scenarios (decrypt old backups)
SKIP	No validation (import everything)	Testing only (security risk!)

Example: Import expired certificate (for legacy data decryption):

curl -X POST https://api.ankatech.co/migration/private-keys \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "kid": "old-expired-key",
    "p12FileBase64": "...",
    "validationMode": "IMPORT_ONLY"  # Allow expired
  }'

✅ Success: Key imported with status EXPIRED ⚠️ Restrictions: Can decrypt old data, CANNOT encrypt new data

Use case: Decrypt archived data from 2020 (certificate expired in 2022)

Bulk Import Workflow

Import Multiple Keys from Single PKCS#12

Scenario: Java keystore with 10 certificates (signing, encryption, backup keys)

Automatic kid generation:

curl -X POST https://api.ankatech.co/migration/private-keys \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "kid": "prod-keys-2024",
    "p12Password": "keystorePassword",
    "p12FileBase64": "...",
    "kidStrategy": "AUTO"
  }'

✅ Result: 10 keys imported with auto-generated IDs:

prod-keys-2024-signing (alias: signing-cert)
prod-keys-2024-encryption (alias: encryption-cert)
prod-keys-2024-backup1 (alias: backup-key-1)
... (7 more keys)

API returns: Array of 10 key objects (one per imported key)

Manual kid Control

Scenario: You want specific kid names for each certificate

Manual mapping:

curl -X POST https://api.ankatech.co/migration/private-keys \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "kid": "prod-keys-2024",
    "p12FileBase64": "...",
    "kidStrategy": "MANUAL",
    "kidMappings": {
      "signing-cert": "corp-signing-2024",
      "encryption-cert": "corp-encryption-2024",
      "backup-key-1": "corp-backup-2024"
    }
  }'

✅ Result: Keys imported with your specified IDs (not auto-generated)

Batch Import from Multiple Files

Scenario: 50 PKCS#12 files from different legacy systems

Script approach:

#!/bin/bash
# Bulk import script

for p12file in legacy-keys/*.p12; do
  KID=$(basename "$p12file" .p12)
  P12_B64=$(base64 -i "$p12file")

  curl -X POST https://api.ankatech.co/migration/private-keys \
    -H "Authorization: Bearer $TOKEN" \
    -d "{
      \"kid\": \"$KID\",
      \"p12Password\": \"$PASSWORD\",
      \"p12FileBase64\": \"$P12_B64\"
    }"

  echo "Imported: $KID"
  sleep 1  # Rate limiting (adjust as needed)
done

Performance: ~10 keys/minute (limited by PKCS#12 parsing overhead)

Result: All 50 keys available in AnkaSecure within 5 minutes

Import from Cloud Providers

Import from AWS KMS

Limitation: AWS KMS doesn't export private keys (security design)

Workaround options:

Option 1: Export public key only (for signature verification):

# AWS: Export public key
aws kms get-public-key --key-id alias/my-rsa-key --output text --query PublicKey | base64 -d > aws-public.pem

# AnkaSecure: Import public key
curl -X POST https://api.ankatech.co/migration/import/public-key \
  -H "Authorization: Bearer $TOKEN" \
  -F "[email protected]" \
  -F "keyId=aws-imported-001"

Operations allowed: Verify signatures only (no signing, you don't have private key)

Option 2: Generate new key in AnkaSecure, export to AWS (reverse flow):

# AnkaSecure: Generate key
curl -X POST https://api.ankatech.co/keys \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"algorithm":"RSA_4096","exportable":true}'

# Export public key
curl https://api.ankatech.co/keys/{keyId}/public \
  -H "Authorization: Bearer $TOKEN" > anka-public.pem

# AWS: Import public key (create external key)
aws kms import-key-material --key-id ... --public-key file://anka-public.pem

Result: AnkaSecure becomes source of truth, AWS references it

Option 3: Migrate data without importing keys: - Decrypt data in AWS KMS - Re-encrypt in AnkaSecure with new ML-KEM keys - Retire AWS KMS keys

See full AWS KMS migration guide (coming soon)

Import from Azure Key Vault

Azure supports PKCS#12 export (unlike AWS):

# Azure: Export certificate with private key
$cert = Get-AzKeyVaultCertificate -VaultName "myVault" -Name "myCert"
$secret = Get-AzKeyVaultSecret -VaultName "myVault" -Name $cert.Name
$secretBytes = [Convert]::FromBase64String($secret.SecretValueText)
[IO.File]::WriteAllBytes("azure-export.pfx", $secretBytes)

Then import to AnkaSecure:

P12_BASE64=$(base64 -i azure-export.pfx)

curl -X POST https://api.ankatech.co/migration/private-keys \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "kid": "azure-imported-key",
    "p12Password": "",
    "p12FileBase64": "'$P12_BASE64'"
  }'

✅ Success: Azure key now in AnkaSecure (portable!)

Import from Google Cloud KMS

Similar limitation to AWS: GCP KMS doesn't export private keys

Workaround: Same as AWS options (public key only, or reverse flow)

Security During Import

HSM Protection

All imported keys automatically wrapped with Hardware Security Module (HSM):

Process: 1. Your PKCS#12 imported to AnkaSecure 2. Private key extracted (in-memory only, never persisted plaintext) 3. Wrapped with HSM KEK (Key Encryption Key) 4. Encrypted key stored in secure keystore 5. Original PKCS#12 discarded from memory

Result: Private key NEVER exists on disk in plaintext (same protection as native AnkaSecure keys)

HSM integration: SoftHSM (trial), Luna/nShield (production)

Multi-Tenant Isolation

Problem: SaaS platform with 1000 tenants - ensure keys don't leak between tenants

AnkaSecure isolation: - ✅ Separate keystores per tenant (database-level isolation) - ✅ JWT scoping: Can only import keys to YOUR tenant - ✅ Audit logs: All imports logged with tenant ID - ✅ Access controls: RBAC enforced (only authorized users can import)

Guarantee: Tenant A cannot access Tenant B's imported keys (or even know they exist)

Password Security

Best practice: Use strong passwords for PKCS#12 files during import

What AnkaSecure does with passwords: - ✅ Used only for PKCS#12 decryption (in-memory) - ✅ Never logged (password redacted from audit logs) - ✅ Never stored (discarded after key extraction) - ✅ Transmitted over TLS 1.3 (encrypted in transit)

Anti-pattern: DO NOT use weak passwords like "password", "123456", or empty passwords (even in dev)

Advanced Import Scenarios

Scenario 1: Import Certificate Chain

Problem: PKCS#12 contains leaf cert + 3 intermediate CAs + root CA

AnkaSecure handling: 1. Extracts leaf certificate (contains private key) 2. Validates chain (leaf → intermediate1 → intermediate2 → intermediate3 → root) 3. Stores full chain (for signature verification) 4. Returns leaf kid (primary identifier)

Chain verification (automatic):

Leaf cert signed by → Intermediate3
Intermediate3 signed by → Intermediate2
Intermediate2 signed by → Intermediate1
Intermediate1 signed by → Root CA

Use case: TLS certificates, code signing certificates, S/MIME certificates

Scenario 2: Import Self-Signed Certificate

Problem: Legacy system uses self-signed cert (no CA chain)

AnkaSecure handling: - Validation Stage 6 (Trust Anchor) skipped for self-signed - Key still imported (no chain validation needed) - Operations allowed (encrypt, decrypt, sign, verify)

Example:

curl -X POST https://api.ankatech.co/migration/private-keys \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "kid": "self-signed-key",
    "p12FileBase64": "...",
    "validationMode": "IMPORT_ONLY"  # Self-signed often "expired"
  }'

Use case: Internal dev certificates, testing, legacy PKI without proper CA

Scenario 3: Import Key Without Certificate

Problem: PKCS#12 contains only private key (no certificate)

AnkaSecure handling: - Key extracted successfully - No certificate validation (skipped) - Operations allowed but certificate-dependent features unavailable

Example: Raw RSA private key:

# Convert PEM to PKCS#12 first (OpenSSL)
openssl pkcs12 -export -inkey private.pem -out keyonly.p12 -nocerts

# Import to AnkaSecure
curl -X POST https://api.ankatech.co/migration/private-keys \
  -d '{"kid":"raw-rsa-key","p12FileBase64":"..."}'

Use case: Legacy keys without PKI infrastructure

Upgrade Imported Keys to Composite

Add PQC Layer to Imported RSA Key

Problem: You imported 500 RSA keys, now need quantum resistance

Solution: Upgrade to composite keys (RSA + ML-KEM) without re-encryption

Step 1: Import RSA key (done in Quick Start):

# Imported key: "my-imported-rsa-key" (RSA-4096)

Step 2: Upgrade to composite (30 seconds):

curl -X PATCH https://api.ankatech.co/keys/my-imported-rsa-key/upgrade \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "upgradeType": "ADD_PQC_COMPONENT",
    "pqcAlgorithm": "ML_KEM_1024",
    "mode": "HYBRID_KEM_COMBINE"
  }'

✅ Result: my-imported-rsa-key now uses RSA + ML-KEM (same kid!)

Decryption behavior (backward compatible): - Old data (encrypted with RSA only) → Decrypts with RSA component ✅ - New data (encrypted with RSA+ML-KEM) → Requires both components ✅

Zero re-encryption needed for existing data!

Benefits: - ✅ Quantum resistance added instantly - ✅ Existing applications continue working (same keyId) - ✅ Gradual migration (old data decrypts, new data uses PQC) - ✅ NIST SP 800-227 compliant

Learn more about composite keys

Troubleshooting

Error: "Invalid PKCS#12 password"

Symptom:

{"error":"INVALID_INPUT","message":"Invalid PKCS#12 password or corrupted file"}

Causes: 1. Wrong password 2. File corrupted during transfer 3. File is not PKCS#12 format (e.g., PEM file)

Fixes:

# Verify file is PKCS#12
file mykey.p12
# Should output: "mykey.p12: data" or "Java KeyStore"

# Test password locally (OpenSSL)
openssl pkcs12 -in mykey.p12 -noout -password pass:yourPassword
# Should output nothing (success) or "Mac verify error" (wrong password)

# Re-export from source system with known password

Error: "Certificate expired"

Symptom:

{"error":"VALIDATION_ERROR","message":"Certificate expired on 2024-06-15"}

Solution: Use IMPORT_ONLY mode (allows expired keys for legacy data decryption)

curl -X POST https://api.ankatech.co/migration/private-keys \
  -d '{
    "validationMode": "IMPORT_ONLY",  # Override STRICT mode
    ...
  }'

✅ Result: Key imported with status EXPIRED, can decrypt old data

Error: "Payload too large"

Symptom:

{"error":"PAYLOAD_TOO_LARGE","message":"PKCS#12 file exceeds 20MB limit"}

Cause: PKCS#12 file > 20 MB (typically multi-key keystores with many certificates)

Fixes:

Option 1: Split into smaller PKCS#12 files

# Extract individual keys from large keystore (OpenSSL)
openssl pkcs12 -in large.p12 -nocerts -out key1.pem
openssl pkcs12 -export -inkey key1.pem -in cert1.pem -out key1.p12
# Repeat for each key

Option 2: Contact support for size limit increase (enterprise customers)

Error: "Weak algorithm rejected"

Symptom:

{"error":"VALIDATION_ERROR","message":"RSA-1024 is below minimum key size (2048 bits)"}

Cause: Legacy key using weak algorithm (RSA-1024, MD5 signatures)

Fix: Cannot import for security reasons

Alternative: Generate new strong key in AnkaSecure, migrate data

# Generate RSA-4096 (strong)
curl -X POST https://api.ankatech.co/keys \
  -d '{"algorithm":"RSA_4096"}'

# Re-encrypt data from RSA-1024 to RSA-4096
# (requires access to plaintext)

Import Limits & Quotas

Trial Tier

Limit	Value	Notes
Max PKCS#12 size	20 MB	Per file
Max imports/day	100	Resets at midnight UTC
Max keys total	1,000	Across all tenants
Supported algorithms	RSA, ECDSA, Ed25519	Full 81 algorithm support

Production Tier

Limit	Value	Notes
Max PKCS#12 size	100 MB	Configurable (contact support)
Max imports/day	Unlimited	No daily quota
Max keys total	1,000,000	Soft limit (contact for more)
Bulk import API	✅ Available	Parallel imports supported

What's Next?

Ready to import your keys? - 🚀 Try the 5-minute quick start (scroll to top) - 📥 Download bulk import script (Bash template) - 📊 Migration assessment tool (inventory your keys) - 📧 Request import assistance (we'll help with complex scenarios)

After importing: - Upgrade to composite keys - Add PQC layer to RSA keys - Analyze compatibility - Check which keys can migrate - Re-encrypt data - Transform RSA ciphertext to ML-KEM - Migration strategy - Complete migration roadmap

Explore import sources: - Import from AWS KMS - Public key import - Import from Azure - PKCS#12 export - Import from on-premise HSM - PKCS#11 support (contact support)

Have questions? Email [email protected] or join our community forum

Last updated: 2026-01-07 | Version: 3.0.0