Letsencrypt: Free SSL Certificates for NGINX

I always wanted all of my sites to run over SSL, but it also didn’t seem worth the expense of buying certificates for all the domains I own. Enter Let’s Encrypt which offers free 90 day SSL certificates. This guide shows how to install and use letsencrypt to generate SSL certificates for NGINX running on CentOS 7, however it should be similar on other supported systems. A bit about Let’s Encrypt from their site:
Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit. Let’s Encrypt is a service provided by the Internet Security Research Group (ISRG).
The key principles behind Let’s Encrypt are:
- Free: Anyone who owns a domain name can use Let’s Encrypt to obtain a trusted certificate at zero cost.
- Automatic: Software running on a web server can interact with Let’s Encrypt to painlessly obtain a certificate, securely configure it for use, and automatically take care of renewal.
- Secure: Let’s Encrypt will serve as a platform for advancing TLS security best practices, both on the CA side and by helping site operators properly secure their servers.
- Transparent: All certificates issued or revoked will be publicly recorded and available for anyone to inspect.
- Open: The automatic issuance and renewal protocol will be published as an open standard that others can adopt.
- Cooperative: Much like the underlying Internet protocols themselves, Let’s Encrypt is a joint effort to benefit the community, beyond the control of any one organization.
Install Letsencrypt
Install letsencrypt
with yum
. Next generate a strong Diffie-Hellman key – you can specify a different path but you need to change it in the Nginx server
block.
yum -y install letsencrypt openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048
Update Nginx
Edit your Nginx configuration to listen on HTTP and HTTPS, and respond to Let’s Encrypt domain validation requests to /.well-known
. Go ahead and add the SSL configuration, but no keys (since they don’t exist yet).
server { # Domain validation is on port 80, SSL is served on 443. If available include "http2", otherwise remove it. listen 80 443 ssl http2; # Hostnames to listen on, you will pass each of these to letsencrypt with "-w www.example.com" server_name www.example.com; # Your document root, you will pass this path to letsencrypt with "-w /var/www/www.example.com/html/" root /var/www/www.example.com/html/; # Add SSL Keys here once they are generated # Use TLS (so don't use old version of SSL) ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; ssl_dhparam /etc/ssl/certs/dhparam.pem; ssl_session_timeout 1d; ssl_session_cache shared:SSL:50m; ssl_stapling on; ssl_stapling_verify on; # handle letsencrypt domain validation location ~ /.well-known { allow all; } # handle all requests... location / { } }
Generate SSL Keys
Validate the configuration, and when it passes reload Nginx. You can then generate an SSL key with letencrypt
using the --webroot
method. With this method you need to pass your web root with “-w /path/to/your/webroot
” and each domain you want an SSL for with “-d www.example.com -d example.com -d images.example.com
“, and so on. The first time you run Let’s Encrypt you will need to accept some terms, enter your email, etc, but subsequent runs won’t ask for this.
# validate nginx configuration nginx -t # reload nginx configuration service nginx reload # generate SSL keys letsencrypt certonly --webroot -w /var/www/www.example.com/html/ -d www.example.com
Add Certificate and Key to Nginx
Once the keys have generated, you will need to add the certificate and key to your Nginx configuration. Edit the server
block and add the following – you may need to change the path for the letsencrypt
location on your system. Don’t move them since you will need to be able to renew them every 90 days.
# ssl certs from letsencrypt ssl_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem;
Load Site Over SSL
Validate the Nginx configuration again, then reload the service. Once it is up, you can use curl
to validate that it is serving requests over SSL.
# validate nginx configuration nginx -t # reload nginx configuration service nginx reload # see if you can load your site over SSL curl -s https://www.example.com
If you have trouble validating your domain and get 403 errors and use SELinux, it’s possible that you will need to run the following command to give nginx permission to read the .well-known directory.
chcon -Rt httpd_sys_content_t /var/www/yoursite/.well-known
Auto Renew Certificates
Your certificate will expire every 90 days so it’s easiest to set up a cron job to automatically check for soon to expire certificates once per day so they can be renewed – this is why we don’t want to move the certs out of the /etc/letsencrypt/live/...
directory. You may need to reload nginx as well if the certificate is updated but this should generally be transparent to clients. Edit your crontab by running crontab -e
and adding the following to check for updates at 1AM.
# LetsEncrypt Renewals 0 1 * * * letsencrypt renew >/dev/null 2>&1 && service nginx reload
Note that your certificates will only be renewed if they are close to expiration, otherwise the system will skip it and continue using the currently installed cert. You want to update at least weekly although daily is prefered to make sure you everything is up to date.
[root@www ~]# letsencrypt renew ------------------------------------------------------------------------------- Processing /etc/letsencrypt/renewal/justinsilver.com.conf ------------------------------------------------------------------------------- Cert not yet due for renewal The following certs are not due for renewal yet: /etc/letsencrypt/live/justinsilver.com/fullchain.pem (skipped)
you are renewing your certificate *every single day* , and so are ppl copy-pasting this all over the internet, please change it to at least once a month (random day& time)
Hi Markos,
Thanks for the comment. There is definitely some merit to what you say, however this code does not actually update the certificate every day, rather it simply checks for an update daily and updates the certs accordingly. The certificate is only renewed if it is close to expiration, otherwise it is skipped. See this excerpt from me running
letsencrypt renew
manually just now –I have had mixed results with Nginx picking up the new certificate without reloading/restarting the process which is why I choose to run mine around 1am when traffic is low (I have more than one site on this server). As you said people all over the Internet might use this post, but as they are distributed around the country and world (and thus timezones) this should cause a natural distribution and thus not everyone would make the check at the same time. It’s also worth noting that this is one request per day per server, which isn’t that much traffic in the big scheme of things (I’m currently building an app that should handle 1000 reqs/sec per thread).
All that said, it would be perfectly fine to run it less often if that suits your needs. My reason for not running it just once a month is backup in case the server or Internet is down and it misses the renewal. Running once a month means that if this happens it might be several days or longer before I noticed on some of my sites.
Of course reducing the load on an awesome free service is great so I will give this some more thought. Thanks!
Just did a bit of research and the recommendation is to run the renewal process weekly at minimum, though daily is prefered – https://serverfault.com/a/790776/141948