Moving server interruption-free

I am planning to move a LE-protected web site to a new server and I’d like some feedback whether the way I propose below is fine, in particular I wonder if there are any problems to be expected with the certificate request process.

  1. Initially, Server A is running the, both http and https. The http version mostly (i.e., except for some weird clients) redirects to https. Also note that HSTS is employed.

  2. Prepare server B (server software, web server [Apache], static data, database etc.). However, do not redirect http to https. Test server B by faking DNS locally.

  3. (Re)activate the http to https redirection on server B. But on port 443, do not run Apache but instead use xinetd to forward all TCP connections to server A.

  4. Update DNS so that points to server B instead of server A from now on. Everybody already picking up the new DNS should connect to server B port 443 (possibly after redirection from port 80) and via xinetd actually talk to server A, so be served the original content properly encrypted with the original server A key. And of course so does everybody who still uses old DNS data.

  5. Wait for DNS change to propagate completely (depending on TTL).

  6. On server B, request a new Let’ Encrypt certificate. In the process, checks will be made against server B (because DNS now says so) over port 80 and the expected content under is correctly served.

  7. Now having a valid cert on server B, we can turn off the xinetd redirection and let the webserver handle port 443.

A minor problem is that during 3, server A thinks that a growing number of clients seem to connect from server B instead of from around the globe, but that should not matter.
Of course, during the whole transition phase, all “editing” activity on the site should be stopped. While this needs to be communicated to a few places in-house, there is fortunately almost no activity with side-effects on the site from users (only newsletter subscription)
But what I am unsure about and want to address specifically on this forum: Does it pose any problem that during phase 5, server B only responds to port 80 whereas it does not for port 443 (or rather, it looks like doing so, but the responses actually come from server A)?

(Perhaps I should add that I have no option of e.g. extracting the private key from server A)

Hi @hagman

sounds too complicated.

If you use a client like Certbot:

You can always use --manual and the dns-validation to create a certificate without having a working webserver.

So install Certbot on your new server, create there a certificate and install it.

Then check your server, perhaps use online tools with ip-check.

If all works, reduce the TTL, then switch your A/AAAA - records.

1 Like

I’d even go a step simpler.

  • (Optional) Force a renewal on server A so you’ve got a full 90 days to do the migration.
  • Prepare server B exactly as it will be configured when live
  • Manually copy the cert/key from the server A to server B so they’re both serving the same certificate.
  • Test server B by faking DNS locally
  • Migrate all DNS records and wait for propagation
  • Configure and verify cert renewals now work on server B

Or even with HTTP-01 validation, if you can manually complete the validation process on the old server.

Unfortunately, copying the cert/key seems not to be an option

Unfortunately, I have practically no possibilities for doing anything manually on server A

Good point, dns-challenge for the initial challenge on server B sounds promisingly simple. However, currently DNS changes are not online² but more handled like a support ticket and hence may take a few hours to complete - which would force me to stop at “Once this is deployed,
Press ENTER to continue” for an uncomfortable length of time. Or is there some option like “resume yesterday’s dns challenge”?

² Perhaps this is a strong hint for me to finally switch to a hidden primary DNS setup or the like before the server migration …

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.