Changing the canonical URL of an LE-encrypted site

Hi,
So we know that ADDING an alternate domain name to a Let’s Encrypt-encrypted is currently unsupported, but what about SWAPPING a “redirect” and the “canonical” domain? We plan to change a canonical URL in the near future, but want to get the site up and deployed in the meantime.

I know a totally reasonable answer is “have you tried?” but no, because I can’t really afford to mess around with the uptime of this site more than I already am.

Thanks for any insight!

1 Like

I’m reasonably sure that the exact same CSR and cert will work after you swap the “canonical” and “redirect” domains. The CSR is created for the combination of the two, without distinction between canonical vs. redirect.

You’ll see that the CSR is created for subjectAltName=DNS:{{ site_hosts | join(',DNS:') }}, where site_hosts is the aforementioned combination of canonical and redirects.

I’d swap the domain names in wordpress_sites then run server.yml with --tags letsencrypt. If it goes awry, you’d probably only suffer 60 seconds of strange site behavior while you SSH in to the remote and

  • delete the CSRs in /var/lib/letsencrypt/csrs
  • delete the certs in /etc/nginx/ssl/letsencrypt
  • run ansible-playbook server.yml -e env=production --tags letsencrypt

Of course, you could test the process on a throwaway domain.

2 Likes

I just gave it a shot and ended up with the dreaded “too many redirects” even after search-replacing my database. Fortunately I was able to fix it by simply swapping the canonical back and reprovisioning again.

I’ll probably just rebuild the droplet and reprovision from scratch. It’s so fast.

Sad to hear it didn’t seem to work. It makes me think of how some browsers cache redirects, like this thread, and on Chrome and Safari (maybe more – I didn’t keep googling).

Suppose your browser caches the original redirect from B.com to A.com. Now you switch the redirect in your Nginx conf, making B primary. Then you go test whether B is working as primary but the browser has cached info saying redirect B to A. So the browser sends you to back to A where you’ve created the new redirect to B, ad infinitum.

If that’s what’s happening, it probably wouldn’t be resolved by rebuilding the droplet and reprovisioning from scratch. You can clear your own browser’s cache but I haven’t researched this to know whether there is any way to do cache busting for other regular visitors to your site. :sweat:

1 Like

Reprovisioning seems to have worked in this case!