This domain is currently hosted on one server, say IP 100.111.112.113. and the DNS entries with the host for this domain point to this IP address. I want the flexibility to change the DNS to point to another server, say, 200.211.212.213, and the minute the DNS entries propagate for users to again be connected to a secure site.
This post shows how to work with different certificates on each server but says it is possible to use the same cert. on both servers. Doing that would mean one less change when altering the DNS entries from a live server to a backup. Provided the method is robust and not too complex, I like to do this. Please can you point me to some instructions. Thanks
Hello @peterk900, welcome to the Let's Encrypt community.
Not knowing anything about your live and backup server software and environment it seem hard to say.
You will likely be better served by finding a community forum for your hosting server and software about keeping live and backup server in sync with each other.
Thanks for your speedy reply.
I wasn't thinking as complex as server sync. I think the route the other guy took, of two certs. is the way I want to go.
You can only create a cert in Plesk if the domain is connected to the server, so I presume I alter the DNS to point to the backup server, get the cert _acme_challenge key, note it and then switch the DNS back to point to live.
If the live server fails or is taken down, then I change the IP addresses on domain host and alter the _acme_challenge key to the value I got above. Once the DNS data propagates then users should see the site, encrypted, on the backup server. Not ultra-elegant perhaps, but this should work, shouldn't it?
Thanks - but I'm not sure I understand.
If I move the domain from a server where the Let's Encrypt certificate is giving a secure site, then the site no longer is secure.
If I use the option to get a Let's Encrypt certificate from within Plesk, I will get a new _acme_challenge TXT entry. If I alter the TXT record on the domain host from the entry which applied on the old server, to the value I've just obtained on the new server... and then wait for propagation.. Will I now have a secure site on the new server?
If you are being constrained by what Plesk can do, then the question is no longer basic AND simple.
(to me) It now sounds like a question that only Plesk can answer definitively.
Perhaps someone here may have such experience - but there is no guarantee of that.
Starting from a domain with a working certificate.
Change the DNS to the new server.
Use Plesk on the new server to register the certificate you already have on the old server. (It will access this from the DNS - which now points to the new server but has the original Let's Encrypt Certificate.
When the DNS propagates to allow your computer to see the site on the new server, the certificate may kick in immediately or you may need to regenerate the Plesk connecton with the certificate by requesting it again. You should see a green "Installed" message.
The key thing is that you do not need to get a a new certificate and update the DNS.
Take-away message - you can move between servers very simply and keep the same certificate!
Yes, that should have been more clear from the posts above. Ideally you will configure the "backup" server whenever the "main" server gets a new certificate, so there is zero downtime on a failover. most people handle this with rsync or custom scripts in the deployment hooks.
Some servers (like Caddy) will allow you to store the certificates in the cloud, so multiple servers can "read" while only one server can "write".
I fail to follow how #5 leads from anything above it [something is missing].
How do those steps explain how one can get a cert without having to update DNS nor get a new cert?
Sorry for any confusion. Let's have another go at point 3.
When you create a certificate for a new domain, Plesk pops up a box with the _acme challenge value. You then add this key to the DNS for the new domain. If you move the domain to another server, Plesk will say you don't have a certificate. If you click the Let's Encrypt option, this time instead of giving you a new key , it goes away to the DNS, finds the key you used on the old server and comes back with a green message saying all is good.
Take-away - if you move domains around to different servers, you don't need to keep on getting new _acme challenge values and waiting for them to propagate. So, if your server crashes, is hacked or you simply wish to change the server, getting the site going again in secured mode is as simple as restoring to the new server, changing the DNS (but not the _acme challenge) and once the new DNS propagate, users will see a secured site.
Summing this up in one sentence - Let's Encrypt Certificates relate to a domain; the key does not contain anything which ties them to a particular server.
I hope this clears up any confusion. But please feel free to amend my post for any remaining inaccuracies or lack of clarity.
I'm not sure if your edit makes more sense to any of us, but the one-sentence summary is absolutely correct. The Certificate is tied to the domain, and you may install the Certificate/Key/Chain pairing onto any server running on any ip address.
If you have two servers that need the same cert and the other server is just a hot backup then the most robust method is to have a cert acquired on each server using DNS validation (not http validation, which tends to be the default).
The reason is that http validation doesn't (easily) work is that it requires your backup server to be able to respond to http validation requests, which it can't do because it's not the server being pointed to by DNS. You can do tricks with redirection from the primary server, shared challenge response storage etc but DNS would often be easier (depending on whether your DNS provider has an API).
The other option as suggested by @Bruce5051 is to sync config from live to backup (certbot config, web server config, cert files and symbolic links).
Also note that you can simply copy the certificate files (e.g. fullchain.pem and privkey) to the other server, configure your webserver to use them then switch to it. You will then have until the cert expires (up to 90 days) to reconfigure certbot etc.
A good way to test a backup (or new) server is to edit your local machines hosts file to point the domain to the new IP, then you can browse that site as if DNS had already been updated.
It isn't hard to write a short script, triggered by cron, that checks to see if a certificate (or in fact any file) has been changed (after being rsync'ed or something from another machine) and if so, reboot the web service.
My backup server rsyncs the certs daily, but sometimes I copy certs by hand. My cron script, running on the backup server, is really low impact, so I have it check every five minutes for a cert change and if found the script reboots web service and sends me an email notifying me of that fact.
The certs are 'wildcard' so they work on either machine out-of-the-box.
