This site is an archive and is no longer updated.
    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%
    LinkedInX

    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.