HardRunbook

CA Migration Runbook

Learn how to move all certificates from one Certificate Authority to another. This comprehensive runbook covers inventory, planning, execution, and cleanup.

1-4 hours per phase
Last Updated: December 2025
Progress: 0/37 complete0%

When to Use

  • Current CA is being distrusted (e.g., Entrust situation)
  • Switching CAs for cost or feature reasons
  • Consolidating certificates under one CA
  • Current CA contract ending

Do NOT Use For

  • Just renewing one certificate (use Certificate Renewal Runbook)
  • Emergency replacement needed (use Emergency Replacement Runbook)

Quick Reference (TL;DR)

  1. Phase 1: Inventory all certificates from current CA
  2. Phase 2: Set up new CA account and test validation
  3. Phase 3: Prioritize by expiration and criticality
  4. Phase 4: Migrate certificates one at a time
  5. Phase 5: Let old certs expire naturally (don't revoke unless compromised)

1Phase 1: Inventory Current State

Objective: Document all certificates that need to be migrated

Scan network for certificates:

# Using nmap to find SSL services
nmap -sV --script ssl-cert -p 443,8443,993,995 192.168.1.0/24

# Check specific host
echo | openssl s_client -connect server.example.com:443 -servername server.example.com 2>/dev/null | \
  openssl x509 -noout -subject -issuer -dates

Create inventory spreadsheet:

# CSV columns:
# Domain, SANs, Expiration, Type, Issuer, Location, Owner, Priority, Status

# Example row:
# example.com, "www.example.com,api.example.com", 2025-03-15, DV, OldCA, nginx-prod-1, ops-team, High, Pending

2Phase 2: Set Up New CA

Objective: Establish account and test processes with new CA

💡 For OV/EV certificates, org validation can take 1-5 days - start early

💡 Test with a non-production domain first to learn the process

💡 If using Let's Encrypt, set up certbot or ACME client and test automation

3Phase 3: Plan Migration

Objective: Create prioritized migration schedule

💡 Prioritization formula: (Days until expiry) × (Criticality weight)

💡 Low score = migrate first

💡 Build in buffer time - things always take longer than expected

4Phase 4: Execute Migration

Objective: Migrate certificates one at a time following standard procedure

Standard CSR generation:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout domain.key -out domain.csr \
  -subj "/CN=domain.example.com"

Deploy and verify:

# Create bundle
cat new-cert.crt intermediate.crt > bundle.crt

# Deploy (nginx example)
sudo cp bundle.crt /etc/ssl/certs/
sudo cp domain.key /etc/ssl/private/
sudo nginx -t && sudo systemctl reload nginx

# Verify
echo | openssl s_client -connect domain.example.com:443 2>/dev/null | \
  openssl x509 -noout -issuer -dates

💡 Do one certificate at a time to limit blast radius

💡 Have rollback plan ready (keep old cert accessible)

💡 Test in staging before production where possible

5Phase 5: Handle Old Certificates

Objective: Properly manage certificates from old CA

💡 Old certs can serve as emergency fallback until they expire

💡 Revocation is only needed if key was compromised

💡 Keep old certs documented for audit trail

6Phase 6: Post-Migration

Objective: Verify complete migration and update processes

Audit all certificates for new issuer:

# Check issuer for each domain in inventory
for domain in $(cat domains.txt); do
  echo -n "$domain: "
  echo | openssl s_client -connect $domain:443 -servername $domain 2>/dev/null | \
    openssl x509 -noout -issuer | grep -o "O = [^,]*"
done

Troubleshooting

Problem: OV/EV validation taking too long

Solution: Contact new CA support. Ensure all required docs are submitted. Some CAs offer expedited validation.

Problem: Old CA won't release certificates/data

Solution: You don't need old CA cooperation - just issue new certs from new CA and deploy them.

Problem: Can't complete domain validation at new CA

Solution: Check DNS propagation, firewall rules, or try different validation method (DNS vs HTTP).

Problem: Some systems still showing old certificate

Solution: Check all servers/nodes, clear caches, verify config points to new cert files.

Problem: Wildcard cert covers dozens of services

Solution: Consider splitting into individual certs for better security. Migrate all at once during maintenance window.