Migrating WordPress with HTTPs Secured by LetsEncrypt to New Server

It’s generally not a problem to have both installed, but if you actually run the newer version (which is almost certainly certbot, as that’s the newer name) it could update the configuration files to a format that may be incompatible with the older version. So if you already did that you’ll have to update your cron job to use certbot too.

I truly appreciate your explanation. That was important. So I now got the certificate via the dns challenge using letsencrypt certonly -d sub.domain.com --manual --preferred-challenges dns and instead of partying all night because it worked, I then re-ran the whole thing using letsencrypt certonly -a webroot --webroot-path=/var/www/html -d sub.domain.com So since I already have my cronjob for letsencrypt setup, am I right in assuming that my certificates will be automatically renewed, including the one originally obtained manually via dns?

Yes, letsencrypt certonly overwrites the renewal configuration as long as you use the exact same set of domains (which you did), so your existing cron job should work.

I take it that means you’ve got everything working now?

I agree with you and I tend to plan things a lot for that very reason. Buy in this case, there was so much to plan and read up on that let's encrypt appeared arguably a minor element in the process. I did not mention the whole complexity in the OP because it was complicated enough to describe: What I left out is that I not only migrated a WordPress site but also a Discourse forum running in a Docker container on the same server and mapped onto its own subdomain and using the NGINX server as a reverse proxy. So I studied exactly how to do this and did not pay too much attention to SSL because when I originally set up the first server, setting up SSL using letsencrypt was so easy, so why should I worry doing it a second time?

And I did almost exactly as you describe and created a dry-run subdomain (except I called it "testwp" (and "test" for the discourse forum) but my conclusion after all this odyssey is that this was precisely the mistake: I should just have accepted some down-time of the site and skip the dry-run setup. It would have been so easy.

For anyone who is not an expert at neither let's encrypt nor webserver administration (like myself) I would recomment this as one of two options. The other option is obtaining the certificates using the dns challenge during the dry-run phase like this:

A third option is manual mode without the dns challenge but I just couldn't get that one to work for the forum subdomain And seeing how easy the dns challenge is, I see no reason to ever again use manual without dns. The only tricky part with the dns challenge is that you apparently have to wait a bit after deploying your token to the dns server and hitting enter to make letsencrypt find it. The first time it didn't work but the second time I waited a couple of minutes (just to be sure) and tada :tada: it worked.

1 Like

Uhm, no, actually I didn’t :frowning: (I simplified the story a bit) This is what I did:

First: letsencrypt certonly -d forum.mydomain.com --manual --preferred-challenges dns

And then (once the DNS pointed to the new server): sudo letsencrypt certonly -a webroot --webroot-path=/var/www/html -d mydomain.net -d www.mydomain.net -d forum.mydomain.net -d test.mydomain.net

(Reason: I already had the other certs on the new server so there was no need of including them in the manual DNS run.)

So this is not going to work?

It will work, in that it should be able to successfully renew the new, combined certificate that you obtained covering all four domains. It will also try, and fail, to renew the separate certificate that you obtained just for forum.mydomain.com. As long as nginx isn’t configured to use that certificate, it shouldn’t be a problem. You can prevent the renewal attempt by deleting the corresponding file from /etc/letsencrypt/renewal. Note that you’ll still get reminder emails from Let’s Encrypt when that certificate is nearing expiry; you can safely ignore those as long as the other certificate is renewed correctly.

You should double-check that nginx is indeed using the combined certificate for that subdomain, though.

I guess I don’t have such a combined certificate:

$ sudo letsencrypt certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Found the following certs:
  Certificate Name: mydomain.net
	Domains: mydomain.net test.mydomain.net www.mydomain.net
	Expiry Date: 2017-07-01 04:01:00+00:00 (VALID: 88 days)
	Certificate Path: /etc/letsencrypt/live/mydomain.net/fullchain.pem
	Private Key Path: /etc/letsencrypt/live/mydomain.net/privkey.pem
  Certificate Name: test.mydomain.net
	Domains: testwp.mydomain.net test.mydomain.net
	Expiry Date: 2017-07-01 00:54:00+00:00 (VALID: 88 days)
	Certificate Path: /etc/letsencrypt/live/test.mydomain.net/fullchain.pem
	Private Key Path: /etc/letsencrypt/live/test.mydomain.net/privkey.pem
  Certificate Name: forum.mydomain.net
	Domains: forum.mydomain.net
	Expiry Date: 2017-07-02 20:57:00+00:00 (VALID: 89 days)
	Certificate Path: /etc/letsencrypt/live/forum.mydomain.net/fullchain.pem
	Private Key Path: /etc/letsencrypt/live/forum.mydomain.net/privkey.pem

Well, at least I’ve got 88 days to solve this problem…

That’s odd; the command you posted above, sudo letsencrypt certonly -a webroot --webroot-path=/var/www/html -d mydomain.net -d www.mydomain.net -d forum.mydomain.net -d test.mydomain.net, would have attempted to obtain such a certificate. Are you sure it succeeded?

Since I still have the terminal open, I can share the output:

$ sudo letsencrypt certonly -a webroot --webroot-path=/var/www/html -d mydomain.net -d www.mydomain.net  -d forum.mydomain.net -d test.mydomain.net
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org

You have an existing certificate that contains a portion of the domains you
requested (ref: /etc/letsencrypt/renewal/mydomain.net.conf)

It contains these names: mydomain.net, test.mydomain.net, www.mydomain.net

You requested these names for the new certificate: mydomain.net, www.mydomain.net,
forum.mydomain.net, test.mydomain.net.

Do you want to expand and replace this existing certificate with the new
(E)xpand/(C)ancel: e
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for mydomain.net
http-01 challenge for www.mydomain.net
http-01 challenge for forum.mydomain.net
http-01 challenge for test.mydomain.net
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Unable to clean up challenge directory /var/www/html/.well-known/acme-challenge
Generating key (2048 bits): /etc/letsencrypt/keys/0001_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0001_csr-certbot.pem

 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/mydomain.net/fullchain.pem. Your cert will
   expire on 2017-07-02. To obtain a new or tweaked version of this
   certificate in the future, simply run certbot again. To
   non-interactively renew *all* of your certificates, run "certbot
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

I noted in another thread that, although the letsencrypt program has been renamed to certbot, packages for certbot still offer letsencrypt as an alias; in this case, if both came from the same package on a given system, they’ll both work in the same way and running either won’t create incompatibilities for the other. We do recommend certbot exclusively for all documentation to ensure that people are using and becoming familiar with the new name.

Aha! The devil is in the details: my letsencrypt and certbot come from entirely different sources.letsencrypt was installed via apt-get install letsencrypt if I remember correctly and certbot was much less straight forward:

sudo apt-get install software-properties-common
sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install certbot

The OS is Ubuntu 16.04.

So they don’t work side-by-side?

True, then those should not be used interchangeably. I suggest only using whichever one is newer (probably certbot), after confirming with --version.

That was close:

P.S. I think 10 characters minimum requirement for posts is enough (the default setting in discourse)

So now we still have the mystery of why certbot (or letsencrypt) reported that it had successfully obtained a certificate for all four domains, but that certificate does not seem to exist on the server. Are you sure you ran both commands (sudo letsencrypt certonly ... and sudo letsencrypt certificates) on the same server?

Did you remove the line from /etc/hosts after testing?

Yes. I have it all in front of me in one terminal window.

I never did anything with /etc/hosts. What line are you referring to?

Meanwhile, I can confirm that the mydomain.net certificate (the first one in the list above) does indeed not seem to contain the forum subdomain because I just noticed that when I call forum.mydomain.net it gives me a NET::ERR_CERT_COMMON_NAME_INVALID, stating that the mydomain.net is not valid for this domain, i.e. for forum.mydomain.net.

So I had to change my NGINX configuration so that the forum.mydomain.net certificate (the third one in the list above) is used in one server block and the mydomain.net certificate in another.

I’m starting to wonder whether we are perhaps looking at a bug…

Update: see here (this is driving me insane) :dizzy_face:

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.


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.