Get Up and Running with LetsEncrypt.org Certificates on CentOS 6 and nginx

If you don’t have git installed, use Yum to install it.

sudo yum install git

Stop nginx, if it’s running. LetsEncrypt needs to bind to port 80 and/or 443 to verify your web server.

sudo service nginx stop

Switch to root and git clone the letsencrypt repository.

sudo su
cd ~
git clone https://github.com/letsencrypt/letsencrypt

Now cd to letsencrypt and run letsencrypt-auto.

cd letsencrypt
./letsencrypt-auto certonly --debug

You’ll be greeted with several questions, first to enter your email address, second to agree to the TOS, and third to enter the domain name that you wish to encrypt.

Note: At this time, even though the prompt specifies you can input multiple domain names, it only works with a single domain name.

LetsEncrypt will do it’s thing for about 10-20 seconds and you’ll be dropped back to the command line with several cryptic looking messages. Don’t stress, do this:

cd /etc/letsencrypt/live/
ls -lha

You should now be looking at a directory for your domain name. If you cd into it, you should be looking at several pem files:

• cert.pem – This is your certificate file
• chain.pem – This is your certificate chain
• fullchain.pem – This is the full certificate chain
• privkey.pem – This is your private key file

If you see all of those files, you’re in good shape! Time to configure nginx.

Now, nginx configurations come in many flavors, and mine is probably much different than yours, so I’ll just give you a crash course here. Feel free to ask specific questions in the comments below and I’d be happy to help you along.

Navigate to /etc/nginx/conf.d and create a copy of your NON-SSL configuration file (call it whatever you want, just append .conf to it). Depending on how you’re set up, it could be default.conf or virtual.conf. You want to modify whichever configuration file that contains your server blocks. Now vi/vim/nano your copy, modify the listen directive inside your server block to reflect the following:

listen 443 ssl;

Now add a few lines below your server_name directive as follows:

ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

Obviously use the correct domain name in the ssl_certificate and ssl_certificate_key directives. The entire thing should look something like this:

server {
	listen 443 ssl;
	server_name yourdomain.com;
	ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
	...

Save the file, take a deep breath, and issue the following command:

sudo service nginx configtest

If you see syntax is ok and test is successful, start nginx by typing

sudo service nginx start

Now your domain should be accessible via HTTPS! Check it out at https://yourdomain.com.

Now, this is only the beginning of your journey to SSL integration. There are likely several tasks left that I suggest you take care of:

1. Don’t disable vanilla HTTP yet, but maybe redirect HTTP traffic to it’s corresponding HTTPS URL. There are several ways to do this, but I suggest an nginx approach.
2. If you’re on WordPress or another CMS, you will likely need to reconfigure your site’s URL within that system. On WordPress, there are a number of ways to do this, my favorite is define( 'wp_home', 'https://yourdomain.com' ); and define( 'wp_siteurl', 'https://yourdomain.com' ); which can be placed inside wp-config.php in your sites root. You may also want to install a plugin to handle all the fancy SSL stuff (like str_replace()ing all your content urls so you don’t get mixed content warnings). I recommend Really Simple SSL by Rogier Lankhorst – it worked right out of the box on my WP Multisite.
3. If you’re on a WordPress multisite, or another site that has more than one domain name, you should generate a certificate for each of those domain names. For instance, on WP Multisite with subdomains enabled and domain mapping, you will have two domain names which need SSL protection, one for the back end and one for the front end.

In future releases of the LetsEncrypt.org libraries, generation of SSL certificates will be far more automated. This is what worked for me in the public beta phase, but there are probably other methods that work as well. Feel free to share what works for you below.

Footnotes:

• LetsEncrypt.org certificates currently have a 3-month lifetime. This means you’ll need to renew your certificate quarterly for now. But it’s very easy to do so, and as mentioned above, there will be some pretty cool automation coming soon to make this seamless.
• If you are indeed running WordPress, get excited – Zack Tollman is working on a plugin to integrate WP-CLI with LetsEncrypt, which will make generating and configuring certificates with WordPress as easy as wp cert new!

Now go forth and be secure!