How to point new domain to existing live site?

Using latest and the greatest full Roots stack and learning many cool things along with using it.

Just registered new domain name for the existing live site to serve it from there soon but meanwhile I need to point temporarily the new domain to the existing web server.

This fresh domain is already connected to shared host server (some one click solution my client has made) that has registered SSL/TLS LE certificate.

I have changed its AAA name records and pointed it to the existing site web server IP.

I get warning/error from the browser to open an insecure connection but when I confirm certificate/connection manually the site front-page shows up from the new domain. Well.

How should I configure it on my existing app side that uses Trellis so that there will be smooth transition without any certificate issue?

Adding canonical url in wordpress_sites.yml with redirect and re-provisioning the production server would solve this or there is some more to do?

Any help with this would be highly appreciated!

When I’m migrating a site into Trellis that already has SSL I do one of two things:

  • If I can get my hands on the existing SSL cert, provision the Trellis server initially with this cert. After DNS has been migrated, re-provision with Let’s Encrypt.

  • If I can’t get my hands on the existing SSL cert, provision the Trellis server initially with a self-signed cert, set DNS TTL very low, swap DNS, then re-provision immediately with Let’s Encrypt

If you’re looking for the smoothest transition go with the first option. Maybe hit up the shared host’s support to see if they can provide you with the cert files.

4 Likes

I’m trying to understand the implications of the new domain. I’ll refer to old.com and new.com.

I assume “insecure connection” browser warnings for new.com were due to the existing SSL cert covering only old.com? Could you get the shared host to create a cert covering both old.com and new.com and get a copy of the cert? If so, use that with Trellis SSL provider: manual (a la @ben’s first bullet). That should avoid downtime during the switch in DNS and servers.

Otherwise, if 5 to 25 minutes downtime isn’t too bad and you can switch DNS and servers at night or something, @ben’s second bullet with provider: self-signed may be most practical.

Otherwise, if downtime is unacceptable, please share some domain and traffic details.

  • Which domains receive traffic before switch? old.com only or both?
  • Which domains receive traffic after switch? new.com only or both?
  • Can you get a copy of the existing SSL cert? (presumably covers only old.com or else you would have use @ben’s suggestion)
2 Likes

thank you @ben and @fullyint for your time and quick answers, really appreciate it!

this domain switch is all about rebranding for the business and smooth domain change/transition lets say during the next 2-3 months

ideally we would like to achieve this:

  • that old domain that is active now receives all the traffic for one more month
  • new domain without any traffic at the moment is just pointing to the old one meanwhile as it is registered and hanging out there already and in case anyone hits it with the browser
  • one month later vice a versa because many people will be looking for this old domain in future

I can access/copy/delete/add certs for the new.com that was registered on shared host.
short downtime is no problem for the live site at night time.

have not done anything else with the certs on both servers. existing old.com cert covers only old and new.com covers only new domain with its cert.

did change AAA records for new domain to point it to the old domain server and I do not know if it is the right way to achieve this at all now …

just to follow up here also that in order to keep both sites (old and new) live for a while:

  • I created brand new dev box locally (also for separate further development)
  • deleted existing certificates from the new domain shared host admin
  • pointed new domain to new server
  • provisioned the prod server first time with ssl provider self-signed
  • then deployed and installed WP in prod
  • checked that prod site was live and reachable without certs from new domain
  • then provisioned again with ssl provider letsencrypt
  • and after that new live site was green and served over https with new certs

then copied db from old live site to new local dev and synced from local to production