Nginx: set up a LetsEncrypt SSL certificate with auto-renewal in 3 easy steps

By -
Unless you have been living under a rock for the past year, you should know by now that you can get SSL certificates free of charge from LetsEncrypt, without registration, and with automatic renewal! This is one of the best thing that's happened to web admins and the web in general in the recent years. The certificates are authentic and work great in all browsers (you get the little green lock icon like everywhere else).

Let's get straight to the point. The three steps are summarized here:
1) Download LetsEncrypt (the application) for your Linux server
2) Run the application to generate a certificate for your domain and set up the monthly auto-renew cron job
3) Add the certificate to your Nginx configuration.

Step 1: download LetsEncrypt

Install git if you haven't done so yet:
# apt-get install git

Use git to get the application and store it somewhere (ie: /root/temp)
# git clone https://github.com/letsencrypt/letsencrypt /root/temp/letsencrypt

Step 2: generate your certificate

The first time you run the command below, you will be asked to provide an e-mail address to be associated to the domain or subdomain, in case you should ever need to recover the key or something. The next time you run the same command (to renew the certificate) it won't be asked.

So run the following command to generate the certificate:
# /root/temp/letsencrypt/letsencrypt-auto certonly -a webroot --agree-tos --renew-by-default --webroot-path=XXX -d YYY
Where: XXX is the full path to your website's root folder. For example /home/www/website.com
And YYY is the domain name or subdomain name (ie: website.com, or something.website.com)

At the time of running the command, your domain must be available to visitors already, because LetsEncrypt's servers will make a verification to ascertain that you are actually the owner of the domain. It will place a hidden /.well-known/ folder with some files in it at the root of your web directory (specified above with --webroot-path).

Certificates generated by LetsEncrypt are valid 3 months at the moment. Also, wildcards are not supported; you can get certificates for domain names and subdomains one by one. Since we don't want to manually renew the certificate every month for every domain and subdomain, we can set up a simple cron job to be ran monthly (it should be run every 3 months ideally but LetsEncrypt are talking about reducing the validity of their certificates so I'd rather not be caught off guard).

Open /etc/cron.monthly and create a new file, make sure to chmod +x to give executable permissions. The first line of the file should be:
#!/bin/sh
And then put the exact same command you ran before to generate the certificate. You can also add  >>/root/temp/certificate-update.log at the end of the command if you want to keep a log of the updates (although I imagine LetsEncrypt generates its own log somewhere too).

Step 3: configuring Nginx

After running the command that generates the certificates, you should have several files in /etc/letsencrypt/live/website.com/ (replace website.com by your own domain). We are going to need just two of them for Nginx: fullchain.pem and privkey.pem.

The beginning of your server block should look like this:
server {
server_name www.website.com website.com;
listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/website.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/website.com/privkey.pem;
ssl_session_cache shared:SSL:20m;
[...]

Don't forget that last line, otherwise Safari and iOS devices won't be able to visit your website (see my recent blog post about it). Save configuration, reload, visit your site and voila, you're done. To make sure the automatic renewal script works, try running it now with the new configuration.

Comments

leilahim said…
We clean and sanitize all areas of your store, ensuring a pleasant shopping experience. A clean and well-maintained workplace enhances productivity and leaves a positive impression on clients and employees. Our commercial cleaning services nyc are customized to meet the specific needs of your business, providing a clean and healthy environment for all.
Tue Jul 02, 08:21:00 PM
Post a Comment

Popular posts from this blog

Nginx error 413: Request entity too large Quick Fix

By -
A quick article today about a common error people encounter with Nginx: the infamous 413 Request Entity Too Large HTTP error. I had the problem myself just yesterday on one of my newly configured servers, so I thought I'd make a blog post about it to make sure I don't forget this next time. Error 413: what does it mean? This error shows up when a visitor sends too much data in the HTTP request. This is normally caused by: • an overy large file being uploaded by the visitor • more generally too much POST data being sent by the client The fix is as simple as setting a directive in your Nginx configuration, read on below. How to fix it? client_max_body_size To fix this, you need to increase the value of the client_max_body_size directive. This directive defines the maximum amount of data Nginx will accept in an HTTP request. By default this value is set to 1 megabyte, meaning if you attempt to upload a file larger than 1 megabyte you'll be getting an  Error ...
Read more

Dealing with Nginx 400 Bad Request HTTP errors

By -
Today I'll write about something I experienced personally, on my websites. Some visitors reported that they were getting a "400 Bad Request" Nginx error randomly when visiting pages. And when they start getting that error, they can't access the site anymore: it'll output the same error no matter the page, until you "clear your cache and cookies". The error is easily understandable and is likely to be caused by... too much cookie data. Every time a visitor loads *any* page/content/file of your website, it sends the cookie data to the server. Cookie data is sent under the form of 1 header line starting with "Cookie: ". Basically, Nginx by default is configured to accept header lines of a maximum size of 4 kilobytes. When a line in the headers exceeds 4 kilobytes, Nginx returns the '400 Bad Request' error. Cookie data sometimes gets big, so it causes the error. It particularly happens on forums like vBulletin, Invision and others...
Read more

Affiliate module for Interspire Shopping Cart

By -
Image
Hello, I have already implemented this module on two shops rather successfully. The concept is quite simple: websites that want to get rewarded through affiliation must link to your website using an identifier in the URL. If your website is http://website.com/, then your links must be of the form http://website.com/?ref=123 where 123 is the affiliate ID. when a visitor clicks the link, the affiliate ID will be placed in a cookie that will expire after 15 days (this can be configured) when the visitor purchases an item: if the affiliate ID cookie is still enabled, the affiliate will be credited of a certain amount, it can be a share of the sale or a fixed amount. affiliate accounts are simple customer accounts, there is no modification to make regarding accounts. When a sale is made, they receive store credit. They can either spend the store credit to purchase items on the store, or they can manually request for a withdrawal (managing withdrawals is up to you). I will detail the i...
Read more