The short answer
Switching certificate authority is not a transfer. Nothing moves across: the new CA runs its own domain validation, and for OV and EV its own organization check, because the Baseline Requirements only permit a CA to reuse validation it performed itself. So you never cut over. You overlap: order and install the new certificate while the old one is still serving traffic, verify the new chain from outside your network, then let the old certificate expire instead of revoking it. Since March 15, 2026 a publicly trusted TLS certificate can be valid for at most 200 days, and that is the entire window you have to arrange the overlap in.
Most people arrive at this page because a renewal quote came in higher than expected, or because a CA they relied on ran into trouble with a root program. If price is what moved you, it is worth comparing the certificate types and current pricing we publish before you plan the migration, since the answer sometimes changes which product you order rather than only who issues it.
What actually transfers between CAs
Nothing does. A certificate is a statement one certificate authority signed with its own key, and no second authority can adopt it, extend it or re-sign it. Moving providers means obtaining a completely new certificate, with new validation, a new chain and, if you automate, a new account at the new CA. The word transfer appears nowhere in the process except in the marketing of companies who would like the change to sound smaller than it is.
That is worth stating plainly because it sets the shape of the whole job. You are not migrating an object from one place to another. You are standing up a second, parallel certificate and then retiring the first one. Every decision below follows from that, including the two that people get wrong most often: starting too late, and revoking the old certificate the moment the new one is installed.
The one genuine exception is your own key material. A certificate signing request is not bound to any authority, so the same CSR and private key can be handed to the new CA and will produce a perfectly valid certificate. Whether you should is a separate question, and the answer is usually no; the FAQ at the end explains why.
Plan an overlap, not a cutover
Run both certificates at the same time. Order and validate the new one while the old one is still answering every request, install it alongside, confirm the chain from a machine outside your network, and only then stop thinking about it. The old certificate stays valid until its own expiry date, which means that for the whole overlap you can revert to the previous files in seconds. That rollback window is worth more than anything else in the plan.
Three to four weeks of overlap is comfortable for a DV certificate and roughly the minimum worth attempting for OV or EV. The constraint used to be soft, since a certificate bought for two or three years gave you an enormous runway. It is not soft any more. Under the CA/Browser Forum schedule adopted in ballot SC-081v3, the maximum lifetime of a publicly trusted TLS certificate dropped to 200 days on March 15, 2026, falls to 100 days on March 15, 2027, and reaches 47 days on March 15, 2029. The longest certificate you can buy today is shorter than the gap most teams used to leave between planning a migration and doing it.
Pick the moment as close to the old certificate's expiry as your validation type allows. Unused days on the old certificate are not refunded as time and cannot be carried across, so switching six months early simply means paying twice for the same six months. Switching three weeks early costs you three weeks and buys a clean rollback path.
CAA is the gate that blocks issuance outright
If your domain publishes CAA records, add the new CA's issuer domain before you place the order. A CAA record set names the certificate authorities permitted to issue for that domain, and under RFC 8659 a CA that does not find itself listed must refuse. This is the only step in a migration that fails hard and silently: the order is simply rejected, nothing on your servers is wrong, and the error text rarely points at DNS.
Keep the old CA listed alongside the new one until the old certificate has expired. Removing it early breaks nothing immediately, but it removes your ability to reissue from the old provider if the migration stalls, and reissuing is exactly what you want available while two chains are in play.
Timing is worth a moment's thought. The Baseline Requirements let a CA issue on the strength of a CAA answer for the record's TTL or eight hours, whichever is greater, so a CA that checked before your edit may still act on the old answer for a while. Dropping the TTL on the record set a day ahead of the change removes the guesswork. If your domain publishes no CAA records at all, every publicly trusted CA is permitted and this section costs you nothing, though a migration is a reasonable moment to start publishing them, which our guide to CAA records covers in full.
Your validation clock restarts from zero
The new CA has to validate everything itself. Section 4.2.1 of the Baseline Requirements permits a CA to reuse validation data only where that CA obtained the data or completed the validation itself, which means your previous provider's work is unavailable to your new one no matter how recent it was. For a domain-validated certificate this is a few minutes of DNS or HTTP proof. For OV and EV it is the full organization check again: registry records, address, phone verification, and confirmation that the person ordering is authorised to do so.
That asymmetry is the single most useful thing to know before you plan the calendar. Teams treat a CA switch as a fifteen-minute task because their last renewal was a fifteen-minute task. But a renewal with the same CA reuses that CA's own stored validation, and a switch cannot.
| Maximum data reuse (per CA) | Certificates issued from 2026-03-15 | From 2027-03-15 |
|---|---|---|
| Domain name and IP address validation | 200 days | 100 days, then 10 days from 2029-03-15 |
| Subject identity information (the OV/EV organization check) | 398 days | 398 days |
| Maximum certificate lifetime | 200 days | 100 days, then 47 days from 2029-03-15 |
Read those numbers as ceilings that apply within a single authority. A CA can lean on its own 398-day organization check to turn your third renewal around in an hour. Your new CA has nothing to lean on, so the first order after a switch is always the slow one, and every order after it is fast again. The cost of moving is paid once.
The new chain is where migrations break
Replace the whole bundle, not just the certificate. Your new leaf was signed by an intermediate belonging to the new CA, so a server still presenting the previous provider's intermediate is offering a chain that cannot be assembled. This is the failure that turns a tidy migration into an incident, and it is almost always the cause when someone reports that a site "broke for some clients" after a CA change.
What makes it treacherous is that it hides from the person checking. Most browsers, on hitting an incomplete chain, quietly fetch the missing issuer using the authority information access extension described in RFC 5280 and render a padlock anyway. The clients that do not do that are the ones you hear from later: command line tools, Java runtimes, older Android devices, payment integrations, and anything speaking to your API from someone else's server.
Verify from outside, with something that will not rescue you. Running openssl s_client -connect example.com:443 -showcerts from a machine that is not yours shows exactly what the server sends, in order, and the chain either builds or it does not. Check every hostname and every load balancer separately, because a bundle updated on three servers out of four fails only for the fraction of traffic that lands on the fourth. Our walkthrough of how certificate chains are built and repaired goes through the diagnosis in detail.
Pinning, trust stores and clients you don't control
Certificate pinning is the one thing a CA switch can break with no warning and no recovery on the client side. A pin that names the old CA's key or the old leaf will reject the new certificate outright, and the device holding that pin has no way to be talked out of it. Browsers are not the risk here: Chrome removed support for the HTTP Public Key Pinning header in Chrome 72, and no current browser honours it.
The risk sits in software that ships its trust decisions inside the binary. Mobile applications, embedded firmware, point of sale terminals, industrial controllers and internal service clients all commonly pin, frequently to a specific intermediate, and usually because someone added it years ago and moved on. Grep your own repositories for pinned hashes and certificate files before you order anything, and treat any pin you find as a release blocker: the updated client has to be in the field before the new certificate goes live.
Private trust stores deserve the same sweep. Java keystores, .NET certificate stores, container images built with a trimmed CA bundle, and appliances with a hand-curated root list will each need the new CA's root present. Public roots are widely distributed, so a current operating system will already have it; a container image pinned to an old base, or an appliance nobody has updated since it was installed, will not. If your environment relies on pinning deliberately, our guide to certificate pinning covers the pin-to-a-backup-key pattern that makes a future switch survivable.
Moving ACME automation to a new CA
Point your client at the new directory URL and register a new account. ACME accounts are per-provider, so an account key registered with one CA means nothing to another, and most commercial CAs additionally require external account binding credentials that tie the new ACME account to your billing identity. Your challenge setup — the DNS or HTTP proof mechanism itself — usually carries over unchanged, which is the one part of a migration that really is easy.
Run both configurations in parallel before you retire the old one. Issue a certificate for a single low-traffic hostname against the new CA, watch a full renewal cycle complete on its own, and only then repoint the rest. A renewal job that silently stopped working is the classic way a CA switch turns into an expiry outage months later, because the failure surfaces at the point where nobody is watching any more.
One change on the horizon is worth noting now. From March 15, 2027, CAs must process the accounturi and validationmethods CAA parameters defined in RFC 8657. Those let a CAA record restrict issuance not merely to a CA but to a specific ACME account and a specific validation method. A genuine improvement, and one more DNS record to update the next time you move.
What to do with the old certificate
Leave it alone and let it expire. Section 4.9.1.1 of the Baseline Requirements sets out the circumstances in which a CA must revoke a subscriber certificate, and replacing one certificate with another from a different provider is not among them. There is no compliance reason to revoke, no security benefit while you still control the key, and one concrete cost: revocation destroys the rollback path you built the overlap to create.
Revoke when there is an actual reason to. A private key that may have been exposed, a certificate carrying information that is now wrong, decommissioned infrastructure whose key you cannot account for, or a departure from a CA whose own trustworthiness is the thing in question: those all justify it. A routine change of supplier does not.
Two things are worth doing before the old certificate lapses. Check whether your contract offers a refund for the unused term, since policies vary and the request usually has to be made while the certificate is still valid. And remove the old CA from your CAA records once nothing depends on it any more, so the record set describes the arrangement you actually have.
Choosing the CA you're moving to
Judge a certificate authority on root program standing, automation support and validation turnaround, in that order. Root program standing is existential: a CA distrusted by a major browser puts every certificate it issued on a clock, and that risk is invisible in a price comparison. Automation matters more every year, because a 47-day certificate in 2029 means roughly eight renewals annually per certificate. Validation turnaround is what you feel on the first order after a switch, and it is the part you can only learn from other people's experience.
Price ranks below all three, though it is usually the reason someone starts looking. The useful comparison is not the sticker figure but the cost across a full term for the certificate type you actually need. A wildcard often undercuts several single names, and a multi-domain certificate can undercut both. We maintain a comparison of the major certificate authorities and how they differ that is a reasonable starting point regardless of who you end up buying from.
For what it is worth on our side: My-SSL issues from Certum, a publicly trusted authority present in the major root programs, and the DV, OV, EV, wildcard and multi-domain products sit on our SSL certificates page with current pricing shown against each. If you are mid-migration and want the organization validation started before your old certificate gets close to expiry, that is the order to place first.
The migration runbook
Nine steps, in order, covering a switch of public TLS certificates from one commercial CA to another. Work from the bottom of your infrastructure upward, and do not skip the inventory even if you are certain you know what is deployed.
- Inventory every certificate and every place it is installed. Load balancers, origin servers, CDN configurations, mail gateways, internal appliances. One forgotten endpoint is the whole outage.
- Search your code and configuration for pins. Pinned hashes, embedded CA bundles, trimmed trust stores in container images. Fix these first; they have the longest lead time.
- Lower the TTL on your CAA records, then add the new CA. Keep the old CA listed. Confirm the record set with a DNS query from outside your network.
- Place the order early, especially for OV or EV. Organization validation starts from scratch at the new CA and is measured in business days, not minutes.
- Generate a fresh key pair and CSR. Reusing the old one works, but a migration is a free opportunity to rotate key material you have been carrying for years.
- Install the new leaf together with its new intermediate bundle. Every server, every load balancer, every hostname. Keep the old files in place under a different name.
- Verify the chain from outside, with a non-browser client. Check each hostname individually, and check behind every load balancer rather than trusting a single request.
- Watch a full automated renewal cycle succeed. Do this before you retire the old configuration, not after.
- Let the old certificate expire, then tidy up. Remove the old CA from CAA, delete the superseded files, and update the monitoring that still names the previous issuer.
None of this makes a migration risk-free, and no configuration is ever beyond failure. What the sequence does is push every irreversible step behind a verification you have already performed, so that the moment something looks wrong you still have a working certificate installed and a way back.
FAQ
Moving your certificates to us
My-SSL is a Certum partner, so certificates ordered here are issued by a publicly trusted authority already present in the major root programs, which is the part of a CA change you cannot fix afterwards. If you are working through the runbook above, start the order while your current certificate still has several weeks left, and give organization validation the time it needs. The DV, OV, EV, wildcard and multi-domain certificates we issue are listed with current pricing, and our team can tell you what validation will require for your organization before you commit to anything.