How I Got Let's Encrypt Setup and Operating on CentOS
Let's Encrypt brings free, trusted SSL certificates to web servers everywhere. The process is automatic if you're running the right combination of stuff, but it can be done manually if necessary.
Join the DZone community and get the full member experience.Join For Free
WARNING: Here there be techy-stuff. Mere mortals, tread lightly.
Translation: I am not responsible if you hose your website trying to implement what I describe here.
The web has been given a wonderful gift by the name of Let’s Encrypt—a free way to get an SSL certificate for your website. Many hosting services are already incorporating Let’s Encrypt in their control panels. Soon there will be no good reason for every website not to be encrypted.
Encryption vs. Verification
Before I go any further, let’s talk about the two things that an SSL certificate can provide for your website.
The first thing that an SSL certificate gives you is encryption. For the uninitiated, this means that before your server sends a single byte of content, it negotiates a secure channel with the client. Then it sends the content. This is what Let’s Encrypt is all about, securing the web.
Previously, you had to purchase an SSL certificate to get encryption. Granted, the price has come way down in the past few years. The last one I actually purchased was for Voices of the ElePHPant and it was only $8 a year! Still, that is a barrier for some people. So, Let’s Encrypt provides a way for everyone to get encrypted websites for free.
The other thing that some commercial SSL certificate do is provide verification. To get one of the more expensive SSL certificates–e.g. not the $8/year ones–you have to prove who you or your business are. The company issuing the SSL certificate will ask you a lot of questions, you may even have to provide a DUNS to be verified. This helps prevent against fraud on the web and is very important to e-commerce sites, banking sites, and any site where you want to ensure the user that they are seeing the site for the company they think they are.
Let’s Encrypt does not provide Verification. If verification is important to your users, don’t use Let’s Encrypt. On the other hand, verification is not real important to sites like this blog, so Let’s Encrypt is a great option.
Doing the Deed
Let’s Encrypt provides wonderful documentation and a lot of automation if you are running Debian. If you aren’t–like me–or if you have a non-standard Apache setup, then you have to do a few extra steps.
So, I am going to describe what I do when I set up a new SSL certificate from Let’s Encrypt and how I keep them renewed automatically.
The following assumes you have installed Let’s Encrypt on your server. I simply cloned the Let’s Encrypt GitHub repo so that I can keep up to date. Twitter follower Nick Le Mouton also pointed out that Let’s Encrypt is also EPEL and that you can use yum to install it as well.
Step 1: Get the Certificate
I have a script to manage this for me. I manually edit it before I run it each time, changing the domain name. Since I don’t purchase more than one domain per month these days–I’m on a domain name diet–this is easier for me than remembering parameters.
The Certificate Script
All of my websites sit in
/var/www on my servers. If you have a different scheme, you will have to adjust.
Ok, that gets my initial SSL certificate. Since I can’t use any of the automation, I have to manually update my apache conf files. How you do this is up to you. Since you are reading this because you have a non-standard setup, it is not possible for me to tell you exactly what you need to do. Honestly, if you don’t know, you probably shouldn’t be reading this in the first place. The important part is that you add these lines to your site’s apache conf file, where ever that may be.
The important part is that you add these lines to your site’s apache conf file, where ever that may be.
Once you’ve done that, restart apache.
Step 2: Get the Renewals
Let’s Encrypt SSL certificates are only good for 90 days. So you will have to renew them at least once a quarter. Thankfully, renewal is not difficult. I have a bash script that I run once a morning. I won’t tell you when but pick a non-standard hour and minute so we aren’t all hitting it at say 1:15 AM.
You run this once a day for a couple of reasons.
First, we are not renewing the certs every day, we are only checking to see if they need renewing. It is a much lighter touch and doesn’t even involve hitting their API unless you actually do need to renew.
Second, if you run it once every 90 days and it fails, your certs will expire before your next run. Even every 30 days is a risk. If you run it every day and you have a cert nearing expiration, if for some reason you can’t reach the API on day 1, you get more chances.
The Renewal Script
The script above will most likely be run either as root or by using sudo as it has to restart Apache automatically.
The big change is
--keep-until-expiring. This tells the Let’s Encrypt script to check the cert and if it’s expiration date is greater than 30 days out, don’t bother with it. If it’s less than 30 days, the script will go ahead and request a new SSL certificate.
There is only one gotcha I have found in doing things this way. If you have more than 3 subdomains, and you have certs for all of them individually–like I do–you can only request 3 SSL certificates per 24 hour period for any given domain. The answer to this is actually very easy, stagger the dates on your certificates. You can have as many as you want as long as more than 3 of them don’t expire on the same day.
I developed these scripts right when the Let’s Encrypt public beta opened. As the project matures, all of this may not be necessary. Before implementing these scripts, check the Let’s Encrypt docs to see if things have changed.
p.s. I hate to say this but I am going to. Change example.com in all of the above scripts to your domain name. An SSL certificate for example.com won’t do you much good. :)
Published at DZone with permission of Cal Evans, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.