Whether switching from a commercial CA to Let's Encrypt, changing commercial providers, or consolidating certificate management, migrating CAs requires careful planning to avoid a service disruption.
Common Reasons to Migrate
- Switching from a paid commercial certificate to free, automated Let's Encrypt
- Consolidating multiple certificates/providers under one system for easier management
- A CA-specific issue (deprecation, trust removal, business reasons) forcing a change
Step 1 — Confirm Your New CA Supports Your Needs
Verify the new CA supports your specific requirements — wildcard certificates, specific validation levels (see Understanding SSL Certificate Types: DV vs OV vs EV), or specific automation capabilities you depend on.
Step 2 — Obtain the New Certificate Before Removing the Old One
Never let there be a gap where no valid certificate is in place — obtain and verify the new certificate is ready before making the actual switch, minimizing risk of an accidental HTTPS outage.
Step 3 — Test the New Certificate in a Staging Configuration First
If possible, test the new certificate on a staging subdomain or environment before applying it to production — catch any unexpected issues (chain problems, browser compatibility) before they affect real traffic.
Step 4 — Update Server Configuration
server {
listen 443 ssl;
server_name yourdomain.com;
ssl_certificate /etc/ssl/certs/new-provider-fullchain.pem;
ssl_certificate_key /etc/ssl/private/new-provider-key.pem;
}Step 5 — Reload (Not Restart) Your Web Server
sudo nginx -t && sudo systemctl reload nginxA reload applies the new configuration without dropping existing connections, unlike a full restart.
Step 6 — Verify the New Certificate Is Actually Being Served
echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -issuerConfirm the issuer shown matches your new CA, not the old one.
Step 7 — Update Any Automation/Renewal Processes
Ensure your renewal automation now points at the new CA/process, and disable or remove any automation for the old CA (e.g. an old Certbot renewal cron job if migrating away from Let's Encrypt, or vice versa).
Step 8 — Update Certificate Pinning If Used (Rare, But Check)
If you're using HTTP Public Key Pinning or certificate pinning in a mobile app connecting to this domain, a CA change likely requires updating those pins — a genuinely significant coordination point if applicable to your setup, since it affects client-side code, not just server configuration.
Step 9 — Monitor Closely After the Switch
Watch for any client-side errors or connectivity issues in the hours/days following the migration — particularly relevant for older or unusual client software that might have compatibility quirks with the new CA's specific certificate chain.
Step 10 — Cancel/Let Expire the Old Certificate Appropriately
Once confident the migration is successful, cancel any paid commercial certificate subscription no longer needed, or let the old certificate naturally expire if no ongoing cost is involved.
Common Errors
Some visitors see certificate errors after migration — often a caching issue (browser or intermediate proxy caching the old certificate) that resolves within the old certificate's cache lifetime, or genuinely indicates an incomplete configuration update on your end; verify server-side configuration is fully correct first.
Continue Reading
- Understanding SSL Certificate Types: DV vs OV vs EV
- How to Generate a CSR and Install a Commercial SSL Certificate
- How to Test Your SSL/TLS Configuration for Security Issues
Browse more articles in SSL/TLS & Certificates.
