Imagen2: images/moving-the-root-domain-misses-certs-for-other-hosts-2.webp
Schema_json: {"@context":"https://schema.org","@graph":[{"@type":"BlogPosting","@id":"https://hosting.websitemaintenancelab.com/moving-the-root-domain-misses-certs-for-other-hosts/#article","headline":"Moving the root domain misses certs for other hosts","description":"SSL migration planning prevents certificate warnings and traffic loss when every hostname is staged before DNS cutover. SSL migration pitfalls: downtime and.","datePublished":"2026-10-30T16:34:00+00:00","author":{"@type":"Person","name":"Alan Curtis","url":"https://hosting.websitemaintenancelab.com/author/alan-curtis/"},"publisher":{"@type":"Organization","name":"Host Compare"},"image":{"@type":"ImageObject","url":"https://hosting.websitemaintenancelab.com/images/moving-the-root-domain-misses-certs-for-other-hosts.webp"},"url":"https://hosting.websitemaintenancelab.com/moving-the-root-domain-misses-certs-for-other-hosts/","mainEntityOfPage":"https://hosting.websitemaintenancelab.com/moving-the-root-domain-misses-certs-for-other-hosts/","inLanguage":"en-US","articleSection":"Website Migration","about":{"@type":"Thing","name":"SSL certificate migration"},"mentions":[{"@type":"Thing","name":"DNS"},{"@type":"Thing","name":"Server Name Indication"},{"@type":"Thing","name":"Content Delivery Network"},{"@type":"Thing","name":"IPv6"}],"keywords":"SSL migration pitfalls: downtime and cert errors when moving domains"},{"@type":"HowTo","@id":"https://hosting.websitemaintenancelab.com/moving-the-root-domain-misses-certs-for-other-hosts/#howto","name":"Summarize the safe migration sequence","step":[{"@type":"HowToStep","position":1,"text":"List every hostname and service that accepts TLS."},{"@type":"HowToStep","position":2,"text":"Lower DNS TTL 24 to 48 hours before cutover."},{"@type":"HowToStep","position":3,"text":"Issue, install, and test the full certificate chain on the new endpoint."},{"@type":"HowToStep","position":4,"text":"Test the new IP directly with SNI before changing public DNS."},{"@type":"HowToStep","position":5,"text":"Change A, AAAA, and CNAME records together."},{"@type":"HowToStep","position":6,"text":"Keep the old server and certificate ready for rollback."}]}]}
SSL migration downtime usually comes from an incomplete endpoint list, not the certificate itself. Before changing DNS, validate a certificate for every live hostname. Preload it on the new origin. Lower DNS TTL 24–48 hours before cutover.
Summarize the safe migration sequence
Move traffic only after every production hostname passes certificate and application tests on the new endpoint.
- List every hostname and service that accepts TLS.
- Lower DNS TTL 24 to 48 hours before cutover.
- Issue, install, and test the full certificate chain on the new endpoint.
- Test the new IP directly with SNI before changing public DNS.
- Change A, AAAA, and CNAME records together.
- Keep the old server and certificate ready for rollback.
Use this approval rule: Change public DNS only after every production hostname returns the expected certificate. Confirm the full intermediate chain, HTTP status, and application response when forced to the new IP.
1. Inventory hosts
2. Lower TTL
3. Stage certs
4. Test new IP
5. Cut over DNS
6. Hold rollback
Map every TLS hostname before DNS
Build a complete endpoint inventory before ordering or moving a certificate.
List public and hidden hostnames
Include the apex, www, APIs, admin panels, mail services, autodiscover, CDN names, load balancers, origins, and split-DNS names. Test A and AAAA routes separately. Stale IPv6 often creates failures that seem random.
Choose coverage that matches names
Use SAN coverage for distinct names. Remember that *.example.com covers only one subdomain level. It does not cover example.com or api.us.example.com. Redirects cannot fix missing certificate coverage. TLS finishes before HTTP redirects begin.
A hosting move keeps the same FQDNs. The existing certificate may be reusable if you can deploy its private key safely. The provider must also allow export.
Moving from oldbrand.com to newbrand.com creates a new hostname set. It needs valid coverage for both domains during the transition. Moving app.example.com to portal.example.com also needs explicit coverage for the destination name.
Certificate names must match every live route.
Build a TLS hostname inventory for each scenario. Include redirects, login hosts, APIs, www, and mail-related names. SAN certificate coverage must match every live name.
Wildcard limits still apply. *.example.com does not cover the apex or nested names like api.eu.example.com.
Stage DNS and certificates on the destination
Prepare and validate the destination before making DNS the public switch.
Lower TTL and record current DNS
Lower changing records to 300–600 seconds, 24 to 48 hours ahead. Then record nameservers, A, AAAA, CNAME, MX, TXT, and CAA values. A lower TTL reduces cache risk. It does not remove old resolver data at once.
Validate and install the full chain
Complete validation first. Install the leaf certificate, private key, and intermediate chain on the correct SNI listener. Then test the new IP with curl --resolve and openssl s_client.
Approve the deployment only if the hostname, SAN, issuer, dates, chain, and application response are all as expected.
Plan the old and new certificates as separate production assets. Complete domain control validation, or DCV, for new names before DNS cutover. This matters when validation uses DNS TXT records, HTTP files, or a managed CDN path.
Reissue a certificate if the destination cannot import the private key. Reissue it when the hostname list changes. Reissue it when key-rotation policy requires a new key pair.
A multi-domain SAN certificate can cover old and new FQDNs for a short time. Every required hostname must be included. Track renewal dates closely.
Keep the old certificate valid through the DNS TTL window. Also wait for IPv6 routes, CDN propagation, and critical service checks. Revoke it only after no dependency reaches the old endpoint.
Test cutover and preserve a rollback path
Switch DNS only after direct tests pass for every production hostname.
Check CDN and proxy certificate paths
Confirm the certificate shown by the CDN edge. Confirm the certificate the origin requires. Keep the CDN active, test edge and origin separately, and verify public A and AAAA answers after cutover.
| Visible symptom | Check | Corrective action |
|---|
| Certificate mismatch | `openssl s_client` with `-servername` | Add the SAN or fix the SNI listener. |
| Unknown issuer | Inspect `-showcerts` output | Serve the intermediate chain. |
| Only some users fail | Compare A and AAAA answers | Correct stale routes and retain old TLS. |
| CDN 525 or handshake error | Test edge and origin separately | Align CDN mode and origin TLS. |
Roll back on defined triggers
Set triggers for certificate warnings, API failures, mail failures, 5xx growth, or critical names showing the old certificate. Restore recorded DNS values and keep the old endpoint online. Do not revoke its certificate during the incident.
Fix errors before rollback
Fix a missing intermediate or wrong SNI binding in place only after direct tests prove origin health. Roll back when the cause is unclear or widespread. Roll back if it affects authentication, payments, APIs, or mail traffic.
This method does not apply unchanged to a same-hostname renewal on the same infrastructure. It also differs when one closed platform manages DNS and certificates. Even then, validate renewal status, CAA records, IPv6, CDN behavior, and critical endpoints before expiry or a platform change.
Use repeatable checks before and after DNS cutover. Run dig A example.com +short and dig AAAA example.com +short against public resolvers. Confirm that IPv4 and IPv6 answers point where expected.
Test an unpublished origin with curl --resolve www.example.com:443:203.0.113.10 https://www.example.com/ -I. The response should show the expected HTTP status. It should not show a certificate warning.
For SNI testing, run openssl s_client -connect 203.0.113.10:443 -servername www.example.com -showcerts. Confirm the leaf hostname, expiry date, issuer, and full certificate chain. Include all intermediate certificates.
Test both routing and TLS before cutover.
After public DNS changes, use SSL Labs to find chain, protocol, and hostname issues. Test the CDN certificate path separately from the origin. Record results in the DNS rollback plan. This helps isolate a failed route quickly.
Common questions
Use the exact failing hostname to select the next check.
Can I move a certificate to another host?
Yes, if hostnames stay unchanged and you securely move the certificate, private key, and intermediate chain. Install them on the correct SNI listener.
Does changing hosting require a new certificate?
No, not for the same valid hostnames. A new hostname needs certificate coverage for that name.
Why do some users see the old certificate?
They may reach old A, AAAA, CDN, or split-DNS routes. Keep the old endpoint available through the planned TTL window.
Does a wildcard cover the root domain?
No, *.example.com does not cover example.com. Request both names through SAN coverage.
Should I disable my CDN during migration?
No, unless a verified vendor procedure requires it. Test the edge and origin certificates separately.
What causes an SSL handshake failure after migration?
Typical causes are wrong SNI routing, an incomplete chain, incompatible TLS settings, or CDN-to-origin validation failure.
The essential points:- List every TLS hostname, including `www`, APIs, mail, CDN, and IPv6 routes.
- Stage and verify the full certificate chain on the new endpoint before public DNS changes.
- Use direct SNI tests to approve cutover and diagnose failures.
- Keep the old route and certificate available until caches and critical service checks are clear.
Related sources
These articles can help you explore the topic in more depth:
