Lets Encrypt on Ubuntu using Apache, Nginx, or Lighttpd Cheat Sheet

If you are using Lets Encrypt (www.letsencrypt.org) certificates on your Ubuntu servers, you may find the following information useful if you work with Apache, Nginx, or Lighttpd.

Installing Lets Encrypt on Ubuntu 14.04 (or older)

Reference: https://www.vultr.com/docs/setup-lets-encrypt-with-apache-on-ubuntu-14-04

apt-get install git
git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt
/opt/letsencrypt/letsencrypt-auto

The 3rd line sets up Lets Encrypt and installs any necessary dependencies such as Python.

Ubuntu 16.04 install instructions

Reference: https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04

apt-get install letsencrypt

Note: The remaining portion of this document uses /opt/letsencrypt/letsencrypt-auto and /opt/letsencrypt/certbot-auto command line tools as found when installing on Ubuntu 14.04 or older. If you are using Ubuntu 16.04 or newer, simply run the command letsencrypt and certbot without the full path or the additional -auto from the command line.

Setup your server so you can create certificates without having to stop your web server

I will not explain aliases in detail, but essentially you need to create an alias URI for /.well-known/. It can be shared among all of your virtual hosts. Lets Encrypt uses this folder to save folders and files that are used in the confirmation process for creating new and renewing existing certificates.

Create a working folder for Lets Encrypt:

mkdir -p /var/www/letsencrypt/.well-known/

Then setup your web server to use this working folder for the .well-known URI path on your server.

Apache .well-known Example

Create a file called letsencrypt.conf with the following.

Alias "/.well-known/" "/var/www/letsencrypt/.well-known/"
<Directory "/var/www/letsencrypt/.well-known">
 AllowOverride None
 Options None
 Require all granted
</Directory>

If you place this file in the conf-enabled folder (/etc/apache2/conf-enabled/letsencrypt.conf) then simply restart your Apache web server. Otherwise you will need to make a symbolic link in your conf-enabled folder to where you saved your letsencrypt.conf file.

Do not forget when ever making configuration changes to Apache to run the following before restarting your web server.

apache2ctl configtest

Nginx .well-known Example

Create a file called letsencrypt.conf with the following.

location ~ ^/\.well-known/(.*)$ {
 alias /var/www/letsencrypt/.well-known/$1;
 # No need to log these requests
 access_log off;
 add_header "X-Zone" "letsencrypt";
}

Then in your nginx.conf file near the top of the server { } add the following line:

 include /path/to/your/letsencrypt.conf;

Do not forget when ever making configuration changes to Nginx to run the following before restarting your web server.

nginx -t

Lighttpd .well-known Example

Add the following in your lighttpd.conf file. Note the += is for adding to an existing set of alias URLs. If you have no alias.url values, then simply remove the + but leave the equal. Learn more about Lighttpd aliasing here.

alias.url += ( "/.well-known/" => "/var/www/letsencrypt/.well-known/" )

Do not forget when ever making configuration changes to Lighttpd to run the following before restarting your web server.

lighttpd -t -f /etc/lighttpd/lighttpd.conf

Creating New Lets Encrypt SSL Certificates

You can now create Lets Encrypt certificates without your server having to be shut down temporarily.

/opt/letsencrypt/letsencrypt-auto certonly --webroot --manual-public-ip-logging-ok -d example.com --agree-tos -m you@example.com --text  -w /var/www/letsencrypt/

Replace example.com and you@example.com with your email address and your host name. Remember if your host name starts with www., leave off the www. as it is not necessary, a certificate without the www. also works with the www.

Renew certs

/opt/letsencrypt/certbot-auto renew

certbot-auto uses previous settings to renew the cert in the exact same way it was created so no extra parameters are necessary

Reference: http://letsencrypt.readthedocs.io/en/latest/using.html#renewing-certificates

You can create a file in the /etc/cron.weekly/ folder to renew Lets Encrypt certificates weekly. Even though it will run weekly, Lets Encrypt is smart enough not to renew certificates until there is 30 days or less remaining. This gives you plenty of overlap in case for some reason one week failed to renew.

Example bash file /etc/cron.weekly/letsencrypt

#!/bin/bash
/opt/letsencrypt/certbot-auto renew
You may want to use the > /dev/null 2>&1 trick at the end of the command line to surpress errors from coming from your cron tasks via email.

Deleting SSL Certificates

When we no longer wish to maintain SSL for a host name, we need to delete the renewal config file.
rm /etc/letsencrypt/renewal/example.com.conf
This file includes information where the SSL certs are located and the options used when the SSL cert was first created.
This is not the same as revoking an SSL certificate. This simply no longer renewing the certificate every 2-3 months.
SSL Cert files are saved in the following path by folder for each host
/etc/letsencrypt/live/
Specific SSL files are located within the host name folder
/etc/letsencrypt/live/example.com/
Important reference to the pem files:
cert = /etc/letsencrypt/live/geeknewscentral.com/cert.pem
privkey = /etc/letsencrypt/live/geeknewscentral.com/privkey.pem
chain = /etc/letsencrypt/live/geeknewscentral.com/chain.pem
fullchain = /etc/letsencrypt/live/geeknewscentral.com/fullchain.pem

Note: “chain” is specifically for Apache and the SSLCertificateChainFile  setting, which is now obsolete as of 2.4.8. This is a good thing as now Nginx and Apache use the same fullchain and privkey files. Lighttpd is still not as simple, see note below.

Though all files are saved in the pem format, other systems and platforms use different file extensions rather than filenames to identify the differnet files. Here is a quick cheatsheet in case you need to map previous files to new files.

type (explanation) - letsencrypt - other examples
cert (public key) - cert.pem - example.com.crt, example.com.public.key
privkey (private key) - privkey.pem - example.com.key, example.com.private.key
chain - (chain key) chain.pem - gd_bundle.crt, alphasslroot.crt, etc...
fullchain (concatenation of cert + chain) - fullchain.pem - fullchain.crt

Pem files and their use on Apache, Nginx, and Lighttpd

Apache 2.4.8 and newer

SSLCertificateFile /etc/letsencrypt/live/example.com/privkey.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/fullchain.pem

Note that there is no SSLCertificateChainFile option, it now uses the fullchain.pem which combines the cert.pem with chain.pem.

Apache 2.4.7 and older

SSLCertificateFile /etc/letsencrypt/live/example.com/privkey.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/cert.pem
SSLCertificateChainFile /etc/letsencrypt/live/example.com/chain.pem

Note that we are not using the fullchain.pem, instead we are linking to the cert.pem and chain.pem on 2 separate configuration lines.

Nginx

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

Lighttpd

Lighttpd Note: The cert and privkey need to be combined for Lighttpd

cd /etc/letsencrypt/live/example.com/
cat privkey.pem cert.pem > ssl.pem

Then link to the certificates in your lighttpd config settings.

ssl.pemfile = /etc/letsencrypt/live/example.com/ssl.pem
ssl.ca-file = /etc/letsencrypt/live/example.com/chain.pem

If you are automating Lighttpd renewals, you will need to add an extra step that concatenates the privkey.pem with the cert.pem before restarting/reloading Lighttpd

While searching the Internet for examples of setting up Lighttpd, I found some examples show using the ssl.ca-file using the fullchain.pem. Though this will also work, that is not technically correct as the ssl.pem already houses the cert.pem
Please feel free to leave a comment if you find an error and/or have additional notes which may be helpful for others.

Updating XP and Vista to support WebDAV Web Folders from Apache – Patch KB907306

If you are familiar with WebDAV or even Subversion and use Windows XP/Vista, you will appreciate this tidbit of information.

You can browse a WebDAV server in Windows XP and Vista using Windows Explorer. There is a problem though, Windows XP and Vista will try to use NTLM authentication (Active Directory) to authenticate with the server. If you configure your Apache WebDAV server with either no, basic or digest authentication, then you will hit a roadblock. Luckily Microsoft created the KB907306 patch. Unlucky for myself, other websites refer to the patch number missing the last digit ‘6’. This will drive you crazy when you know you should be able to copy/paste the KB number in Google and quickly find the download page on microsoft.com. Other documents will say to search for KB90730. You should be searching for KB907306. You can search for “Software Update for Web Folders“, but you will also get a lot of other search results that are not nearly as helpful. Hopefully this blog post will save some folks the aggravation.

Now that you’re here, there is no need to search! The patch is available from the following link: http://www.microsoft.com/downloads/details.aspx?FamilyID=17c36612-632e-4c04-9382-987622ed1d64&DisplayLang=en

CW10 – May 22, 2008 – Zend PHP 5 Certification Study Guide and Open Flash Charts

Angelo discusses the Zend PHP 5 Certification Study Guide 2nd edition and explains how to implement Open Flash Charts into your PHP project.

Don’t forget to E-mail comments and suggestions to compiledweekly AT gmail.com.

Links:

Download This Episode

Apache Module Rewrite – URL Rewriting Guide

If you’re looking for clean and simple resource or reference on the Rewrite Module in Apache, look no further. This page is the most useful and to the point resource on the subject I have come across to date.

Module Rewrite – URL Rewriting Guide

If you are looking for a cheat sheet, check out AddedBytes (previously I Love Jack Daniels)’ mod_rewrite Cheat Sheet for a Rewrite Module cheat sheet as well as others.

Source for Lighttpd mod_redirect rewrite module to use status code 302

Lighttpd web server, also known as Lighty, is an excellent web server and has potential to replace Apache completely.  I am slowly migrating web sites that use feature specific settings in Apache to use Lighty.  A few months ago I ran into a problem with Lighty’s ModRewrite alternative for rewriting URLs.  Lighty uses two separate modules to handle internal rewrites and Location: redirects.  It uses the common HTTP 301 Moved Permanently status code.  For most circumstances, this works well but in some cases the application may require that the redirect only be temporary and return the HTTP 302 Found status code.  Instead of modifying the mod_redirect.c source and changing the http_status code value from 302 to 301, I added new code to support a new url.redirect parameter url.redirect-found.

I’ve posted the source to the Lighttpd bug tracking system in hopes it will be added to a future version of Lighty.  http://trac.lighttpd.net/trac/ticket/1446

This addition should help the Lighty web server to be capable of handling the appropriate HTTP status codes for all situations that may arise for the web site in question.

Lighty Web Server Fast with static pages

Three months ago I started looking at an alternative web server to serve URL redirects.  The need arose when I found that Apache web server would consume a lot of system memory when testing simulated spikes to the server.  Apache could handle between 1,200 to 1,700 requests a second.  Though the number of requests per second was satisfactory, the memory usage when these simulated spikes was concerning.

I did some research and came across Lighttpd web server, also known as Lighty.  Lighty took some time to figure out, but once I did I found the XML style configuration files were not hard to implement and understand.  I did find the rewriting to be rather limited in comparison to the mod_rewrite module found in Apache.  Never the less, I was able to duplicate the rewrite that I had in Apache in Lighty.  For my application, I did have to modify the Lighty source code that way redirects returned a 302 HTTP response (It defaulted to 301 without any way of changing in the configuration files).

After performing similar tests with the same server configured with Lighty, I found that Lighty could handle between 3,900-4,100 requests per second.  On top of this, memory usage was minimized to only a fraction of the total memory available on the server.  Processor usage did increase, but was not substantial enough to warrant the change.

I am currently experimenting with combining Lighty with Apache services on one server in order to utilize the best of both worlds.  See my post on the lighttpd.net forums: http://forum.lighttpd.net/topic/13830

Lighty may be able to also serve dynamic PHP files using FastCGI faster than Apache.  I am still concerned that PHP will not function correctly since it is not multi-threaded friendly.  I also have security concerns based on what I’ve seem with source code being exposed with a popular web site recently, I am not ready to take on that much risk.

Quick .htaccess to list files in directory on apache web server

If your web server to supports .htaccess files and you can specify “Options” from within your .htaccess file, then the following is a quick 1 line solution to your file listing needs.

So you just uploaded a tun of pictures to a web directory and you want a list of all the images.  Since the only types of files in the directory are images, the security risk of displaying the list diminishes.  In actuality, the list of images can be quite useful especially when trying to find a specific one.

The answer, create a 1 line .htaccess file with the following: Options Indexes

If you don’t have control over your apache configuration files and this option is not available to you, don’t fret.   Chris Snyder created an excellent php script that allows you to list the contents of a web directory.

Link: http://chxo.com/scripts/image-list.php

This script is very useful, I’ve customized it for my subversion repository in order to display a list of repositories in the root of the subversion web server.

Save bandwidth and faster downloads with Apache mod_deflate

I’ve been auditing apache web logs from statistics gathered in AWStats. I found 6 different IP addresses that are using a lot of the servers bandwidth. After looking at the logs, I discovered one of the IP addresses was a spammer and the rest are from web robots or bots. One bot used over 2.5GB of traffic last month. That is unbelievable. That is 2.5% of the months bandwidth. Of course Google and Yahoo combined have downloaded almost 30GB, but we want Google and Yahoo to index our sites. So what can we do to save our bandwidth and still provide the information to the search engines? Compress it with Mod_deflate!

The mod_deflate module in Apache is not new. What is new is the trend to use it. The deflate module uses gzip compression and is relatively fast in comparison to the bandwidth time. You can do the math, but if your page was 1MB and took 20 seconds to download, and compressed it is 250k and takes 1 second to compress, 5 second to download, and 2 second to decompress, the compression method is faster. You can crunch numbers till you are blue in the face, but the basic premise holds true.

First, you need to make sure the mod_deflate module is enabled in apache. Look for the line in your apache configuration files and uncomment:

LoadModule deflate_module modules/mod_deflate.so

Then add the following lines within a <Location> or <VirtualHost> section.

SetInputFilter DEFLATE

The above will compress everything. Instead of compressing everything, especially if you have a lot of files on your web site such as images, media, zip files, etc.. that are already compressed, you may want to only add compression for particular content types. To compress specific content types, replace the SetInputFilter with one or more of the following.

AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/x-httpd-php

If you work with other content types such as application/xml, you can add those as well.

You can test your server by using the GID Network gzip test located here: http://www.gidnetwork.com/tools/gzip-test.php

Now that your web server is using compression, you can focus on other things like programming or eating pizza.

Test configuration before restarting Apache

Have you ever made a lot of changes to your apache conf files on your web server that you were worried that the changes may result in apache not restarting? I know I have. There is a way to check your changes before you restart the running service.

cmd:

httpd -t
# or
/usr/sbin/httpd -t

If everything was entered correctly, you should see the following message printed: “Syntax OK”.

If there are errors, it will print the first one it finds and exits. Otherwise it will print all the warnings if any and then print the “Syntax OK” message.

If you keep each virtual host in a separate configuration files like I do, then you can check the specific httpd.conf file.

cmd:

httpd -t -f /path/to/virtual/httpd.conf