I have an nginx web server with an SSL certificate provided by Let’s Encrypt using Certbot. For example, this site is publically available at https://example.com

New server
I’m creating a new server that will replace that existing server once everything is setup and deployed correctly.

I want it to be available at https://beta.example.com while setting it all up, and then at https://example.com once approvals are met.

https://beta.example.com could be available now as no other server serves a site at that subdomain, but example.com would only work when I eventually update the DNS records.

I need the existing web server obviously to continue without impact until the new server is ready.

How can I create an SSL certificate for the new server in preparation for it to take over eventually?

Problem with verifying domain
When I run certbot, it tries to access https://example.com as part of the verification, however it fails because that domain points to the IP address of the existing server.

Failed authorization procedure. example.com (tls-sni-01): urn:acme:error:tls :: The server experienced a TLS error during domain verification :: remote error: tls: handshake failure

- The following errors were reported by the server:

Domain: example.com
Type: tls
Detail: remote error: tls: handshake failure

To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address. Additionally, please check that you have an up-to-date TLS configuration that allows the server to communicate with the Certbot client.

Is there an appropriate process to resolve that, given what I'm trying to do?

  • Simply copy the relevant example.com files over from the current server to the new server. Potentially first point beta.example.com to the current server's ip-address to get that hostname included in the example.com cert. – HBruijn Dec 11 '17 at 12:55
  • Let's Encrypt won't fail with "remote error: tls: handshake failure" if the old server is working normally. Instead it would say it received the wrong certificate. – Matt Nordhoff Dec 11 '17 at 22:57

Try using a reverse proxy. Create two virtual hosts on your old server, which owns example.com, and direct beta.example.com there. The virtual host with beta.examply.com should strip HTTPS and reverse-proxy requests to actual server via HTTP. Both virtual hosts will use same certificate. All Letsencrypt stull will be on older server for now.

When you are ready, you copy certificate to new server, update DNS and wait for it to settle (at least for DNS TTL seconds). When you see all requests are reaching the new server, you can either reverse things or just move Letsencrypt stuff and move to new completely.

  • Maybe also have all http requests 301 to https and terminate at the proxy (only do proxy pass for the https site so http file verification stays local) – Jacob Evans Dec 11 '17 at 20:50
  • 1
    True. I always do like this: on my reverse proxies .well-known is the only not proxied place (resolved locally), everything else is redirected to https virtualhost, which proxies requests to real servers. Letsencrypt is configured on the reverse proxy. – Nikita Kipriyanov Dec 15 '17 at 6:48

You cannot use beta.example.com to verify a Letsencrypt certificate for the domain example.com.

You can copy the current certificate files from the server running example.com and place them in the server running beta.example.com. If you are on a Linux based system, those files can be located at /etc/pki/tls/certs/ folder.


In addition to the other answers that recommend copying the certificate to the new server you should also copy your certbot configuration. This will ensure your renewal process continues to work as expected.

For me those files are in /etc/letsencrypt. Make sure you preserve file permissions and symlinks during the copy (rsync -a).

Also remember to setup the cronjobs or whatever you use to renew your certificates. Once you switch over to the new server you can test the renewal process using certbot renew --dry-run.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.