nginx+letsencrypt

Automate LetsEncrypt SSL Certificate Renewals for NginX

For those in a rush: this blog post shows you how to use free SSL certificates and have then renew perpetually (in theory) so they are near zero hassle to use.

It is always nice to automate things. This saves you a lot of time and lets you concentrate on the things that actually matter and make a difference.

Renewing SSL certificates is one of those very important things that you don’t want to screw up and where, if you make a mistake, it could cost you dearly in terms of downtime or even money. Traditionally SSL certificates have been quite expensive so people have used HTTPS on their websites sparingly as a result.

Enter LetsEncrypt.

The Electronic Frontier Foundation; or EFF, came up with a great solution to this recurring problem. They became a certificate authority and provide the tools to, easily, automate the process of generation, signing, delivery and verification.

This project helps you encrypt communication between clients and servers via HTTPS. It is a necessary but not sufficient start in helping you achieve online anonymity; though not the only one required.

Best of all, the LetsEncrypt certificates are free which is very neat. The downside is they are only valid for a maximum of three months then need renewing. At CloudSigma we use these certificates but we have automated the renewal process so they are just as convenient as commercially paid for certificates to work with.

Here’s how to automate your deployment of these awesome certificates and, forget about this renewal overhead safely… at least for a while.

Installation of Certbot

First of all, you need to install the required software. It is easy enough in any major distros:

Configuration of NginX

Now, since NginX is not fully supported at the time of writing, we need to configure certbot to do all we want it to do and not suffer isues.

First, we will setup /etc/letsencrypt/cli.ini; which will contain all the default settings we want.

Please, remember to update “email” to the best email for this from your side.

Now, everytime we run certbot, it will be configured to use:

  • standalone as the authenticator method
  • manual installation method
  • renew by default

So, the only thing left to provide is the domains. these were intentionally left out of the configuration (yes, you could add them there, if you like) and for a valid reason.

First of all, we’re using the standalone authentication method. This means that our NginX instance must be stopped so that this works. Don’t worry, it’s just a little bit of downtime depending on how many certificates you want to get.

So, next, we write the script that will renew/install the certificates for us and we will put it in: /usr/local/sbin/letsencrypt-renew; as per the Filesystem Hierarchy Standard 3.0.

Now, as you can see, you need to specify each and every sub-domain you will be using for a domain. The limit right now is 100 sub-domains per domain.

Keep in mind that:

  • The first -d will determine the name of the certificate file. So, in my case, I will end up with example.tld.pem and someother.tld.pem.
  • You can have 100 sub-domains in a domain; but you can, always, generate separate certificates. This means you can stick to one -d per call and you will get as many separate cert files as you need.
  • It is much faster to have as many bundled certificates in one file than have many cert files.
  • You can use these certificates for email.
  • Beware of doing this too often. You will get “rate-limited” if you do ;D.

Now, the cron job!

Done.

Summary

Here’s what we did:

  • We installed certbot.
  • We configured it with some sane defaults.
  • We created a script that stops NginX, renews our certificates and starts NginX again (please note this only works only systemd-enabled systems)
  • We created a cron job to run that script on a monthly basis (yes the certificates are valid for three months but with a monthly renewal you leave a two month buffer in case the process fails before the current certificate will expire)

References

00fdaa19dc42fd452f5fdd9cc5cd3087?s=80&r=g

About Renich

DevOps @ CloudSigma during the day, Creative Commons artist and producer on my free time... Yeah, that means going to play my guitar or piano on the streets sometimes. You can listen to my music in my personal project: Renich or my Rock project: introbella. And I'm sure I have a cover or two @ YouTube. I am, also, a Fedora and Funtoo maintainer and contributor. In fact, you can just google me "Renich" and you'll find my website and other stuff. I have a blog somewhere; where I write technical stuff as well. I am sure you can't imagine the blog's title 😉 On other matters, I've met Richard Stallman, started the local PHP and Ruby groups and contribute continuously to LinuxCabal.