Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

How I Got Let's Encrypt Setup and Operating on CentOS

DZone's Guide to

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.

· Web Dev Zone ·
Free Resource

Deploy code to production now. Release to users when ready. Learn how to separate code deployment from user-facing feature releases with LaunchDarkly.

Dear Reader,

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.

Encryption

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.

Verification

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

#!/bin/bash
#
# makeCert.sh
# This script requests a cert the first time. This is not the auto renew script.
#
# Set DOMAIN before running
#
DOMAIN=example.com
SITE=$DOMAIN

#
# Make sure this is set correctly
#
ENCRYPTDIR=/opt/letsencrypt

#
# Once it is working, you shoudn't have to change anything below here.
#
cd $ENCRYPTDIR


#
# How many dots are in the $SITE. If more than 1 then it is a subdomain 
# so don't register www as well.
#
FILESEPS=$(echo $SITE | awk 'BEGIN { FS="."} {print NF}')

if [ $FILESEPS -le 2 ]; then
 DOMAIN="$SITE -d www.$SITE "
else
 DOMAIN="$SITE"
fi

#
# Requst the cert
#
./letsencrypt-auto certonly \
 --agree-tos \
 -d $DOMAIN \
 -a webroot \
 --webroot-path /var/www/$SITE/public_html \
 --server https://acme-v01.api.letsencrypt.org/directory


All of my websites sit in /var/www on my servers. If you have a different scheme, you will have to adjust.

Update Apache

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.


 SSLEngine on
 SSLCertificateFile /etc/letsencrypt/live/example.com/cert.pem
 SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
 SSLCACertificateFile /etc/letsencrypt/live/example.com/chain.pem 


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

#!/bin/bash
#
# renewCerts.sh
# This script checks every cert on this server and if necessary, renews it.
#

#
# Configure
#
ROOTDIR=/etc/letsencrypt/live
WEBROOT=/var/www
ENCRYPTDIR=/opt/letsencrypt

#
# Loop and renew
#
cd $ENCRYPTDIR

for SITE in $(ls -1 $ROOTDIR); do

 FILESEPS=$(echo $SITE | awk 'BEGIN { FS="."} {print NF}')

 if [ $FILESEPS -le 2 ]; then
 DOMAIN="$SITE -d www.$SITE "
 else
 DOMAIN="$SITE"
 fi

 ./letsencrypt-auto certonly \
 --agree-tos \
 --keep-until-expiring \
 -d $DOMAIN \
 -a webroot \
 --webroot-path $WEBROOT/$SITE/public_html \
 --server https://acme-v01.api.letsencrypt.org/directory
done


#
# Restart Apache
#
systemctl restart httpd

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.

Gotchas

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.

Wrap-up

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. :)

Deploy code to production now. Release to users when ready. Learn how to separate code deployment from user-facing feature releases with LaunchDarkly.

Topics:
ssl certificates ,apache

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}