Migrating WordPress with HTTPs Secured by LetsEncrypt to New Server

Just a note how I’ve migrated WP/LE sites and domains from a server - done it twice now, although I did have the position that the other server had gone completely (Crissic pulled out of VPS completely at short notice, deleting my server - partly my bad for missing the one (!) email they sent about that). Another when I had to reinstall the server, but also several times upgrade from StartSSL to LE which also kicks off the same warnings you were talking about.

What I found worked was disabled HTST and OCPS stapling - the caching etc causes all kinds of problems. I’ve still got them disabled because I’ll live without A+ for the faff of not being able to update my sites - bad enough running WP Caches and Pagespeed without having ANOTHER step to trip you up. I also copy the data over if there is LE data from /live/ and /archive/ but delete the renewal info - this is important because the renewal confs need to be regenerated. In that sense switching from another cert provider is easier, but you might have to accept some downtime on HTTPS because it might start kvetching about man in the middle attacks, that the cert has suddenly changed - hence removing HSTS etc and clearing browser caches etc. Like you I found that out the hard way, I can understand going insane about it, cos if you just follow Mozilla recommendations you don’t know exactly what each little thing means but that It’s A Good Thing. Servers are complicated enough without all the arcane SSL/TLS stuff. Only mailservers are more opaque!

Then I regenerate the certs using webroot, (I am using NGINX too, and the same OS as you). and force an update of the certs, or delete the /live/ and /archive/ entries for that domain. It’s fiddly, but not as bad as described here - what might’ve helped is using a temp cert for the subdomains, and then only switching to the new cert when it was all ready? Certainly having another cert like StartSSL in a place makes it easier to switch back in a hurry to reduce downtime. But as you said, I think you’ve got to accept some disruption - DNS takes a few hours anyway, and some browsers that previously saw the domain might flag the changed cert.

Another thing I do is I know the usual advice is to band them all together in one cert. Sometimes that’s not great if you have very different sites as subdomains, or want to move them around. Not very flexible. So I do have subdomain certs with different certs, basically www and domain and alias domains together (you know, .com, .co.uk etc that are pointing to the same site), but if blah.domain.net is a different site I create a completely new cert. Doesn’t seem to create any problems as far as I aware.

2 Likes

Hmm, another user recently reported an apparent failure of certbot renew to update the symbolic links pointing to a recently renewed certificate. I wonder if you've got a certificate somewhere in /etc/letsencrypt/archive/ that covers all four subdomains, and the links just haven't been updated?

That's perfectly fine, as long as you don't have one domain with a large number of unrelated subdomains. If you do, you risk running into the rate limits, and while that won't hamper renewals, it might complicate obtaining certificates for any new subdomains.

The directories in /etc/letsencrypt/archive are the same as in /etc/letsencrypt/live. But how can I check whether the certs in /etc/letsencrypt/archive/mydomain.net are for all for subdomains (as I understand it should be) or only for 3 of them as is the case with the live certs as shown here:

I’m not aware of any option within Certbot itself to do that; however you could perhaps use OpenSSL to check. Something like this:

sudo find /etc/letsencrypt/archive/ -name 'cert*.pem' | while read CERT ; do echo "$CERT" ; sudo openssl x509 -text -in "$CERT" | grep DNS: ; done

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