90 days have passed

Well, not yet, so let's be on time for once. I've been using the Let's Encrypt certs without any problems, but their short live span force me to look into the renewal process now. For Apache setups there seems to be an automated thingy, but as I'm using nginx, this might prove to be a bit more tedious. Let's see. The current situation, prior to any renewal actions/attempts, is as described in the original post.

To be using the latest and greatest, I've done a git pull in the letsencrypt repos, resulting in a large list of deltas. Afterwards, letsencrypt-auto wants to update itself.

# ./letsencrypt-auto -h
Checking for new version...
Upgrading letsencrypt-auto 0.5.0.dev0 to 0.4.0...
(...)

Now, let's try to use the built-in renew thing:

# ./letsencrypt-auto renew
Checking for new version...
Requesting root privileges to run letsencrypt...
   /root/.local/share/letsencrypt/bin/letsencrypt --no-self-upgrade renew
   Processing /etc/letsencrypt/renewal/luukhendriks.eu.conf

   -------------------------------------------------------------------------------
   The program nginx (process ID 14968) is already listening on TCP port 80.

(...)

Even though it fails, this looks promising: it knows where my certificates are stored on the filesystem, and without a proper nginx plugin it makes sense that we need to free up tcp/80 by hand.

Additionaly, people were complaining about the fact that one needs to run the letsencrypt scripts as root. There seems to be a privilege check now, as can be seen in the output above.

Oops

Processing /etc/letsencrypt/renewal/blog.luukhendriks.eu.conf
2016-02-20 12:04:10,903:WARNING:letsencrypt.cli:Attempting to renew cert from /etc/letsencrypt/renewal/blog.luukhendriks.eu.conf produced an unexpected error: You've asked to renew/replace a seemingly valid certificate with a test certificate (domains: blog.luukhendriks.eu, luukhendriks.eu, smokeping.luukhendriks.eu). We will not do that unless you use the --break-my-certs flag!. Skipping.

This might come from some failed attempts when I started out with this whole Let's Encrypt thing. Are these perhaps leftovers from the closed beta certs? Looking into that specific .conf file reveals that indeed an old server is used:

(...)
server = https://acme-staging.api.letsencrypt.org/directory
(...)

In my case, part of the problem was that I did not include all my subdomains when I initially generated the certs. This results in multiple certs, multiple .conf files in the renewal directory, and thus in a more cumbersome renewal process. I've added the subdomain to the domains key in the .conf file, and attempted another renewal.

# ./letsencrypt-auto --force-renew renew

The --force-renew was needed as I've just updated the certificate, and the script sees no need for another renewal just yet. First I got a DNS related error, saying there was no A record for my domain. Just ran the same command again, and then it worked. Because of my edit in the .conf file, some small changes in my nginx config were needed, but after that and a simple start/restart, things worked! Or ... well...

Changing domains does not work

Simply adding the extra subdomain is not enough, apparently. The newly added subdomain does not serve a valid certificate, or better put, the generated certificate does not include information on that added subdomain.

The good news is, that the other subdomains worked perfectly fine. So, the renewal approach as described works. In my case, I will generate new certificates with all subdomains included, so a new .conf file is generated.

Don't forget your DANE!

You did create that TLSA record right? Make sure you update it, as it is simply serving a wrong hash now. See the original post for some one-liners on this.