When moving an HTTPS site from one server to another, while keeping the domain the same, and using the default HTTP challenge or TLS-ALPN challenge, there will likely be some downtime, where there will be an SSL error, while the DNS changes take effect. This downtime occurs after the DNS record is changed, and is related to the TTL of the DNS record.
This is because when the SSL Provider, such as Let’s Encrypt, does the ACME challenge, it sends a request to your domain name. It uses DNS to find the IP address for your domain name, and if the change in DNS records hasn’t taken effect, it will go to the old server.
For DNS to work well, it’s good to not have too small of a TTL, because the TTL is used for caching, and caching helps reduce the amount of work networks have to do.
However, you can temporarily reduce the TTL to a small number.
This explains it, in the last paragraph (“The easy solution to this inconsistent state is as follows”).
- jot down what the current TTL is. It’s in seconds. 3600 is 60 minutes, or 1 hour.
- reduce the TTL of the DNS record to a small number, such as 300 (5 minutes) or 60 (1 minute). The above page also proposes 5 seconds, as part of multiple steps, but another site suggests going below 30 seconds won’t make a big difference. Only change the TTL in this step. Keep the value the same - the old IP address.
- wait the old TTL value (if 3600, then 60 minutes)
- change the value of the DNS record to the new IP address. Keep the TTL the same, for now.
- make sure the change was successful
- increase the TTL value to what it was before, or a new value, if you prefer. Some suggest a full day, but if you want to be able to migrate in a shorter period like 30 minutes, choose that time (30*60 = 1800 for 30 minutes).
Another way is to copy the SSL certificates from the old server to the new server. To do that, you need to locate the SSL certificates, securely copy them (using rsync), and put them in the correct location. If it’s from one Caddy server to another, they store the certificates in the same place, so it will be a simple rsync or scp from one caddy data directory to another. If it’s another HTTP server like nginx, the certificates will be elsewhere. If this is the case, one option besides copying from an nginx or apache config to a caddy config is to first install caddy on the old server and let its Automatic HTTPS acquire new certificates (which will be instant since it’s the same host). Since caddy ships as a single binary, this should be simple to set up even if you’re migrating, from, say, an old Linux distribution that no longer has up-to-date packages.