Migrating to a New Certificate Authority Mid-Move

Problem Statement

Hosting platforms come with opinions about certificates. Moving to a managed platform frequently means its automation issues from a different authority than the one you have been using, and that change rides along with the migration without anybody deciding it. Most of the time nothing breaks — but three things can, and each fails in a way that looks unrelated to certificates. A CAA record can forbid the new authority outright, refusing issuance with an error that names DNS rather than TLS. A client with a pinned issuer rejects the new chain while every browser accepts it. And revocation checking configured for the old issuer silently stops working. This page sits under TLS & Certificate Cutover and covers changing authority deliberately rather than by accident.

When to Use This Approach

  • The new hosting platform or CDN provisions certificates automatically from its own authority.
  • You are consolidating several certificates onto one issuer as part of the move.
  • The domain has CAA records, or you are unsure whether it does.
  • Mobile applications, embedded devices, or partner integrations connect to your hostnames.
  • The current certificate came from a commercial authority and the new one will not.

Step-by-Step Instructions

1. Read the CAA Records Before Anything Else

CAA records tell authorities which of them may issue for your domain, and an authority that is not listed will refuse — correctly, and with a message that sends people to look at DNS rather than at the certificate request. Check the apex and any subdomain that carries its own record, because CAA is inherited down the tree until a more specific record overrides it.

# Authorities currently permitted to issue for this domain
dig CAA example.com +short
# e.g. 0 issue "letsencrypt.org"   -> nobody else may issue

Note that CAA is checked at issuance time, not at handshake time, so a restrictive record never breaks a certificate that already exists — it only prevents the next one being created. That is why the symptom appears as a failed request from your platform’s automation rather than as anything visible on the site, and why it can lie dormant for months between renewals before anybody meets it.

2. Add the New Authority Before Removing the Old One

Permit both issuers during the transition. Removing the incumbent before the new certificate is deployed leaves you unable to renew the certificate that is currently serving traffic, which converts a planned change into an expiry incident on whatever schedule the old certificate was already on.

# Add the new authority alongside the existing one, then verify both are present
dig CAA example.com +short
# 0 issue "letsencrypt.org"
# 0 issue "pki.goog"        <- new authority, added before the switch

Check subdomains individually. A CAA record on the apex applies to everything beneath it unless a more specific record overrides, so a permissive apex can be undermined by a restrictive record on one subdomain that somebody added for a specific vendor years ago. Query each hostname you intend to certify rather than assuming the apex answer generalises.

3. Check for Pinning Before You Change Chains

Certificate pinning outside the browser is rare but real, and it is the failure that a browser test cannot possibly reveal. Mobile applications, embedded clients and some payment integrations pin either a specific public key or an issuer, and a chain from a different authority fails validation on a client you do not control and cannot update quickly. Ask the teams who own those clients rather than inferring from the codebase, because the pin is often in a configuration file rather than in code.

# What issuer is currently being presented, and what will replace it
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer

4. Re-point Revocation and Monitoring at the New Issuer

OCSP stapling configuration, any pinned issuer in a security header, and certificate-expiry monitoring all reference the authority in some form. Update each one in the same change as the certificate itself, then confirm stapling still works — a stapling configuration left pointing at the old issuer degrades quietly rather than erroring, adding latency to every handshake while appearing to function.

# Confirm a staple is present and valid after the switch
openssl s_client -connect www.example.com:443 -servername www.example.com \
  -status </dev/null 2>/dev/null | grep -A2 'OCSP Response Status'
Three ways a certificate authority change breaks things CAA records, client-side pinning and OCSP stapling compared by the symptom each produces when the issuing authority changes and where the failure appears. None of these look like a certificate problem Mechanism Symptom Visible in a browser? CAA record issuance refused, DNS-flavoured error n/a — never issued Client-side pinning one integration fails, site is fine no OCSP stapling config slower handshakes, no error no Expiry monitoring silence, then an expiry no Only the first row stops you before the change; the other three let the change succeed and surface days later.
Check CAA before requesting, and ask the owners of non-browser clients before switching chains.

Worked Example

A team moves from a commercial certificate to a platform-managed one during a hosting migration. The platform’s automation requests a certificate and fails immediately with a DNS-related error, which sends two engineers looking at their nameservers for twenty minutes. The actual cause is a CAA record added years earlier when the commercial certificate was purchased:

$ dig CAA example.com +short
0 issue "digicert.com"

They add the platform’s authority alongside it, issuance succeeds, and the certificate deploys. Two days later a partner reports that their server-to-server integration has started failing while the website works normally — the partner had pinned the previous issuer. The team keeps the legacy hostname serving the old certificate while the partner ships a configuration update, then completes the switch.

Both problems were discoverable before the window with a single dig and one email, and neither was visible from any browser.

Safe ordering for a certificate authority change Adding the new authority to CAA, issuing and deploying the new certificate, verifying non-browser clients, and only then removing the previous authority. Add first, remove last — never the other way round Add new to CAA both permitted Issue + deploy new chain live Verify clients apps, partners, APIs Remove old one authority Removing the incumbent before the new certificate is deployed leaves you unable to renew the one currently serving traffic. The third box is the one that gets skipped, and it is the only step that can detect a pinned client.
Both authorities permitted at once costs nothing and removes the window in which neither can issue.

Keep the previous certificate installed and valid while both are in play. Nothing prevents an origin holding several certificates, and retaining the old one gives you a same-minute reversal if a pinned client turns up that nobody knew about — which is a far better position than reissuing under pressure from an authority whose automation you have just decommissioned.

Verification

Confirm the authority change landed cleanly across DNS, the handshake, and revocation.

# 1. Both authorities permitted during the transition, new one afterwards
dig CAA example.com +short

# 2. The chain now terminates at the intended issuer
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -dates

# 3. Stapling still works with the new issuer
openssl s_client -connect www.example.com:443 -servername www.example.com \
  -status </dev/null 2>/dev/null | grep 'OCSP Response Status'

A clean result is the new authority permitted by CAA, an issuer line naming it, an expiry comfortably ahead, and a stapled response marked successful.

What to update alongside the certificate itself Four configuration items that reference the issuing authority and must change with it: CAA records, stapling configuration, expiry monitoring, and any documented pin. The certificate is one of four things that reference the issuer Item Referenced how If left stale CAA records by authority name renewal refused later OCSP stapling by responder URL slower handshakes, silently Expiry monitoring by certificate or issuer no alert on the real expiry Documented pins by key or issuer a client fails after the switch Update all four in the same change as the certificate, then confirm each — three of them fail quietly.
Expiry monitoring is the one most often left pointing at a certificate that no longer exists.

FAQ

Do I need CAA records at all? They are optional and worth having: without them any publicly trusted authority may issue for your domain, and with them only the ones you name may. The migration relevance is that an existing record you did not create can block a new issuer, and that adding one during a migration can block your own automation if the list is incomplete. If you add records, list every authority anything in your estate uses — including the one your CDN uses on your behalf, which is easy to overlook.

How long should both authorities stay permitted? Until the old certificate is fully retired and no renewal path still points at the previous issuer, which usually means through the soak window. There is no cost to permitting two, and removing the incumbent early is the specific mistake that leaves you unable to renew the certificate currently serving traffic. Remove it as a deliberate, separate change once nothing depends on it.

Will changing authority affect rankings or user trust? No. Search engines do not distinguish between publicly trusted authorities, and browsers show the same interface for all of them. The only visible difference is in the certificate details panel, which almost nobody opens. The risks here are technical — CAA, pinning, stapling — rather than reputational.

What if the platform will not let me choose the authority? Then treat the platform’s choice as a constraint and work around it: permit its authority in CAA, confirm no client pins the old issuer, and check whether the platform lets you upload a certificate of your own where a specific issuer is genuinely required. Managed platforms usually support bringing your own certificate for exactly this case, at the cost of taking renewal back into your own hands.

How do I find out whether anything pins our certificate? Ask, then verify. Start with the teams owning mobile builds, embedded devices, and any partner integration that connects server-to-server, because pins are usually a deliberate decision somebody made and can remember. Then check for the technical fingerprints: a Public-Key-Pins header is long deprecated but occasionally still present, and mobile projects often carry a network security configuration file naming the expected issuer. What you cannot do is detect a pin from the server side — the failure happens entirely in the client, which is why this has to be a conversation rather than a scan.

Related

← Back to TLS & Certificate Cutover