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)

Phase 1: Inventory all certificates from current CA
Phase 2: Set up new CA account and test validation
Phase 3: Prioritize by expiration and criticality
Phase 4: Migrate certificates one at a time
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

Export list of all certificates from current CA portal

Document for each: domain(s), expiration date, certificate type (DV/OV/EV)

Identify where each certificate is deployed (servers, load balancers, CDNs, cloud services)

Note any special requirements (EV, code signing, client auth, wildcard)

Identify certificate owners/contacts for each certificate

Export current private keys (if reusable) or plan to generate new ones

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

Evaluate and select new CA (DigiCert, Sectigo, Let's Encrypt, GlobalSign, etc.)

Confirm new CA meets all requirements (certificate types, validation levels, features)

Create account with new CA

Set up organization validation if needed (for OV/EV certs)

Test the issuance process with one non-critical certificate

Document new CA procedures and contacts

💡 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

Sort certificates by expiration date (most urgent first)

Factor in criticality (production > staging > dev)

Assign owner for each certificate migration

Create timeline with target dates for each certificate

Schedule maintenance windows for critical services

Communicate plan to all stakeholders

💡 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

Generate new CSR (or reuse key if policy allows)

Submit CSR to new CA

Complete domain validation

Download new certificate and intermediate chain

Deploy new certificate during maintenance window

Verify new certificate is serving correctly

Update inventory spreadsheet (status: Complete)

Repeat for next certificate

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

DO NOT revoke old certificates unless they were compromised

Let old certificates expire naturally as backup

Remove old CA account access when migration complete

Archive old certificate files for audit purposes

Cancel old CA subscription/contract when appropriate

💡 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

Verify all certificates have been migrated (check inventory)

Update monitoring/alerting for new certificate expiration dates

Update documentation with new CA procedures

Train team on new CA portal/processes

Update automation scripts to use new CA

Conduct lessons learned review

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.

Related Resources

✅ Certificate Renewal Runbook 📖 PKI Disasters: Entrust 2024 🎬 Certificate Lifecycle Demo 🎬 CA Hierarchy Demo

← Back to Checklists Library