As opposed to most SSL certificate issuers, Let’s encrypt is not only free to use but also easy to install and update. This write-up highlights steps I followed to install mine on both Hoo.gy and Hoo.gy Blog.
Motivation to write this article is threefold. First, this article serves as a reference for future SSL certificates needs, using Let’s encrypt. Second, sharing experience with developer community is another form of learning. Third, as a token of appreciation to the team that democratizes this core part of security infrastructure.
This article is divided into 4 major sections:
- Install necessary software
- Generate Key and Certificate
- Install Certificate(s) on Nginx
- Enforce HTTPS redirection
- Certificate Auto-renewal
Install necessary software
Certificate Issuance is done via a bot, Certbot. The bot covers a wide variety of Operating Systems and web servers. The first step was to update and install latest Linux packages, as well as making sure Ubuntu includes a new source of packages.
$ sudo apt-get update
$ sudo apt-get install software-properties-common
$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt-get update
$ sudo apt-get install python-certbot-nginx
The second step in code above, installs certbot on Linux box. The following command is good for Nginx server, but more can be found at eff.org. There are two possible modes to generate SSL certificates. That is going to be the subject of the following section.
Generate key and certificate
The default mode is designed for regular Linux users. Everything is taken care of after you run the next command. Certbot generates proper keys+certificate and automatically update Nginx configuration files.
$ sudo certbot --nginx
For more advanced users, who rather like they key+certificate, and install certificates as it pleases them, this command will help them:
$ sudo certbot --nginx certonly
After generating private key and certificate, you will need to install certificates, re-enforce HTTPS redirection, and to automate certificate renewals.
Install certificate(s) on Nginx
Since you are running Nginx in production, you don’t want anything to mess with your custom configurations. The second command gives you just that. There are two ways to do install certificates: first is to keep your configurations intact, and
symlink new certificates. The second is obviously to change configuration links to a new location. I prefer the latter.
# in /etc/nginx/sites-enabled/[your-config-file]
listen 443 ssl;
For some reasons, I was accustomed to
chained.crt for certificate and
key.crt for the keys. The switch is not that difficult though. Certbot generates same files under slightly different names:
privatekey.pem for keys, and
fullchain.pem for certificates.
Enforcing HTTPS redirections
There is a lot of discussions on this topic. Software developers are the worst people to have a discussion with. We always end up in tribalism, and who does it better. One way that made sense in my case, was to create a new server block in existing configuration file and redirect any request to marching this new server block, to a server block that listens only to HTTPS. The new block looks somehow like the following:
server_name example.com www.example.com;
# redirect, and rewrite all
# links to https://example.com
return 301 https://example.com$request_uri;
# Alternatively: if you want to forward without
# rewriting requested URL
return 301 https://$server_name$request_uri;
How to customize Nginx configuration can be a whole new topic on its own. I cannot conclude this post without talking about two more things: auto-renewal(using a cronjob) and redirect traffic to HTTPS.
SSL certificates issues by Let’s encrypt last for 90 days. Which is not a bad thing on its own. If you have 1000+ servers to update every 90 days, though … that would be a nightmare. Whence you need some sort of automation. How to go about that, is the last topic in this blog post.
First of all, to renew certificate from Let’s Encrypt takes a second … if everything works according to the plan.
$ sudo certbot renew --dry-run # or simply:
# $ sudo certbot renew
# restart the nginx server $ sudo nginx restart
If you are lucky to have a smaller configuration and used auto-renewal strategy, you may have a cronjob similar to the following:
# file: /etc/cron.d/certbot
0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew
Code Snippet from Ishigoya ~ On Serverfault
It is possible to customize frequency, and restart command. The cronjob gives you a way to calibrate dates by using this star format: cronjob [minute, hour, the day of the month, month, the day of week].
- This cron runs every day around 5:30 server time:
30 5 * * * ...
- This one runs same time, every bi-monthly(1st and 15th)
30 5 1,15 * * ...
- This last one runs same time, every two months: 30 5 * */2 *
So your cronjob may end up looking like the following if you wish to renew certificates every day around 5:30 server time.
30 5 * * * certbot renew --post-hook "service nginx restart"
# alternatively: using systemctrl
30 5 * * * certbot renew --post-hook "systemctl reload nginx"
Please consider a donation for this service to service at Let’s Encrypt. Even though thoughts discussed in this article seems simple(not to say naive security-wise), there are enhancements done atop Let’s Encrypt foundations, that makes this choice rock solid. If you work on Containers environment, especially Kubernetes, you should check Kelsey Hightower’s Kube Cert Manager project on Github. Netflix’s Lemur is another alternative to manage certificates, you can read an introductory article here.
Originally published at blog.hoo.gy on March 13, 2018.