Set up SSL/TLS with Let's Encrypt
Let's Encrypt is a Certificate Authority (CA) accepted by popular browsers that provides free certificates to support encrypting websites without drawing browser warnings. It is also supported by a convenient automation tool through the Certbot project. Let's Encrypt certificates support Server Name Indication (SNI), an extension of TLS that allows accepting more than one certificate from one IP address.
This article explains how to configure SSL/TLS with Let's Encrypt on a LEMP web server configured as per the prior articles in this series. Note that the general procedure and configurations may be used with other Certificate Authorities.
Nearly every step in this article requires root level access:
username@servername:~$ sudo -i
Install letsencrypt
The letsencrypt package contains all of the tools necessary to create and manage all of the necessary certificates. Note that if Python is not currently installed, then its various packages will be installed as they are required.
root@servername:~# aptitude install letsencrypt
When a certificate is created, it will be valid for example.com and one subdomain. To verify ownership of a domain, a temporary file will be written to a public directory, and then erased. To support this, make one small edit to the http_server.conf file:
root@servername:~# nano /etc/nginx/global-configs/http_server.conf
Add as the very top line:
location ~ /\.well-known { allow all; }
root@servername:~# service nginx restart
Create the directory:
root@servername:~# mkdir /var/www/example.com/public/.well-known root@servername:~# chown www-data /var/www/example.com/public/.well-known root@servername:~# chmod 775 /var/www/example.com/public/.well-known
Create the certificates:
root@servername:~# letsencrypt certonly --rsa-key-size 4096 --webroot -w /var/www/example.com/public/ -d example.com -d www.example.com -w /var/www/example.net/public/ -d example.net -d www.example.net
The additional domain of example.net is added to demonstrate using the command on multiple domains. Note that the configuration file name and certificate issuance domain will be assigned based on the first domain stated in the above command.
Edit nginx.conf and create the common HTTPS server file
nginx.conf
Edit nginx.conf:
root@servername:~# nano /etc/nginx/nginx.conf
Add at the bottom of the http block:
ssl_session_cache shared:SSL:10m;
The ssl_session_cache will set up a shared cache for SSL sessions across all virtual hosts between all worker processes.
dhparam.pem
The default OpenSSL Diffe-Helman Ephemeral (DHE) parameter is 1024 bits, which is weaker than the key strength of the server's private key, thus clients using DHE will connect with a weaker encryption than non-DHE clients. Generate a strong DHE parameter. Note that this will take some time to complete and will use approximately 100% of one thread (1.00 load) for the duration of the task.
root@servername:~# openssl dhparam -out /etc/ssl/private/dhparam.pem 4096 && chmod 600 /etc/ssl/private/dhparam.pem
HTTPS server common configuration file
Create the HTTPS server file, which includes the common settings for SSL/TLS in an HTTPS server block:
root@servername:~# nano /etc/nginx/global-configs/https_server.conf
Add to the file:
location ~ /\.well-known { allow all; }
location ~ /\. { access_log off; log_not_found off; deny all; }
location ~ ~$ { access_log off; log_not_found off; deny all; }
location = /favicon.ico { log_not_found off; access_log off; }
location = /robots.txt { allow all; log_not_found off; access_log off; }
ssl on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers AES256+EECDH:AES256+EDH:!aNULL;
ssl_prefer_server_ciphers on;
ssl_ecdh_curve secp384r1;
ssl_dhparam /etc/ssl/private/dhparam.pem;
ssl_stapling on;
ssl_stapling_verify on;
resolver <DNS resolver location> valid=300s;
resolver_timeout 5s;
add_header Strict-Transport-Security "max-age=63072000;includeSubDomains";
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
SSL/TLS protocols and ciphers
The ssl_protocols are configured to leave out all variants of the SSL protocol and include only TLS. This is to protect against the POODLE attack. The server should still be able to support the vast majority of devices, and given that it is already operating on SNI, most devices that don't support SNI also don't support any of the TLS protocols.
The ssl_ciphers used are the strongest ciphers available and will yield a score of 100% on the Qualys SSL Labs SSL Report testing. The !aNULL directive instructs openssl not to use any cipher suites that offer no authentication.
Enabling ssl_prefer_server_ciphers instructs the server to prefer server ciphers over client ciphers.
Setting the ssl_ecdh_curve instructs the server to use a stronger curve for ECDHE ciphers from the default curve of prime256v1.
The ssl_dhparam directive tells the server the location of the file to obtain DH parameters for DHE ciphers.
OCSP Stapling
Most clients will verify the validity of a server's certificate through either a Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP). OCSP is typically preferred because the size of the CRLs is quite huge and pinging a server for a single record is a much faster method.
OCSP stapling is configured through several directives.
ssl_stapling
ssl_stapling directive enables stapling of OCSP respones
ssl_stapling_verify enables verification of the responses by the server;
resolver
The resolver configures name servers used to resolve names of upstream servers into addresses. This can be either a domain or an IP address (both IPv6 or IPv4) and can be configured to accept only IPv4. Here are some examples:
OpenDNS IPv4:
resolver 208.67.222.222 208.67.220.220 valid=300s;
resolver [2620:0:ccc::2]:5353 [2620:0:ccd::2]:5353 valid=300s;
OpenDNS with both IPv4 and IPv6:
resolver 208.67.222.222 208.67.220.220 [2620:0:ccc::2]:5353 [2620:0:ccd::2]:5353 valid=300s;
resolver 8.8.8.8 8.8.4.4 [2001:4860:4860::8888]:5353 [2001:4860:4860::8844]:5353 valid=300s;
A local network gateway using only IPv4:
resolver 192.168.1.1 ipv6=off valid=300s;
The resolver_timeout sets a timeout for resolver name resolution.
ssl_trusted_certificate
OCSP stapling requires that the entire certificate chain be available. This is configured in the sites-available file with the ssl_trusted_certificate directive.
Verification
To verify OSCP stapling is working properly, use either the Qualys SSL Labs SSL Server Test and look in the test results for OCSP stapling Yes or run the following command:
root@servername:~# openssl s_client -connect example.com:443 -tls1 -tlsextdebug -status
Note that this command may not work for servers behind firewalls.
The output of a test failure will include the line:
OCSP response: no response sent
The output of a successful test will include:
OCSP response:
======================================
OCSP Response Data:
OCSP Response Status: successful (0x0)
...
HTTP headers
Several directives setting the HTTP headers can be used to enhance security.
HSTS
HTTP Strict Transport Security (HSTS) protects against downgrade attacks by telling a browser that after it has established a secure connection, it should only communicate using HTTPS.
Clickjacking prevention
This setting can prevent clickjacking by setting controls on how a server may be viewed in a frame or an iframe. The example configuration of SAMEORIGIN will allow the site to be viewed in frames of the same origin server, which is a common feature in various popular PHP tools, including WordPress. Optionally, the DENY option could be used to prevent framing from any server. Note that there is an option for ALLOWFROM <URI>, but this is not well support by all popular browsers.
Content Security Policy (CSP) is being adopted and will replace X-Frame-Options with its frame-ancestors option, but this is not yet widely supported.
X-Content-Type-Options
Adding the X-Content-Type-Options prevents MIME-sniffing and is most important on sites that host user-uploaded content.
Add HTTPS server block to sites-available file
Open the sites-available file and add the HTTPS server block.
root@servername:~# nano /etc/nginx/sites-available/example.com
Add below the HTTP server block:
# HTTPS server
server {
listen 443 ssl;
listen [::]:443 ssl;
root /var/www/example.com/public;
access_log /var/www/example.com/logs/access.log;
error_log /var/www/example.com/logs/error.log;
server_name www.example.com;
include global-configs/https_server.conf;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
location / {
try_files $uri $uri/ =404;
}
}
Test then restart nginx.
root@servername:~# nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful root@servername:~# service nginx reload
Navigating to https://example.com (or https://subdomain.example.com) should load /var/www/example.com/public/index.html in a secure session.
Note that if the the local device's ISP has not yet updated to the new DNS records for the server, entering the IP address of the server should bring up the page, but with the browser's certificate warnings. Proceeding through these warnings should allow the user to view the certificate and verify its settings are correct. Presumably, once the DNS records have updated, the certificates should function normally.
Install ntp
The ntp package maintains the system clock instead of having only the default method for time synchronization, ntpupdate, which runs only once, when Ubuntu starts up. It is important for the clock to be synchronized because, theoretically, if a server goes a long time without being restarted, or a motherboard battery failure causes system clock malfunctions, it may end up having issues with the certificate authority.
root@servername:~# aptitude install ntp
Common configurations
The HTTPS server block is just as configurable as the HTTP server block, but some configurations are commonly desired by adminstrators.
Require location to load in HTTPS
To require a file or directory to load only in HTTPS, perform the following.
root@servername:~# nano /etc/nginx/sites-available/example.com
In the HTTP server block, add the following:
location ^~ /path/to/directory/or/file {
return 301 https://$server_name$request_uri;
}
Require subdomain or site to load in HTTPS
To require a subdomain or site to load only HTTPS, perform the following:
root@servername:~# nano /etc/nginx/sites-available/example.com
Add the following server block:
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
access_log off;
error_log /var/www/example.com/logs/error.log;
return 301 https://subdomain.example.com$request_uri;
}
Testing
The Qualys Labs SSL Server Test is regularly updated based on new vulnerabilities and changes in the SSL/TLS standard. Periodically testing a server there is useful for making sure the server is configured correctly and securely.
Next step
Install PHP, that oh-so-popular server-side scripting language.
External links
Strong SSL Security on nginx - Raymii.org is currently one of the most complete tutorials on the web for SSL/TLS settings, and this wiki article borrows heavily from it. Note that the link to the HSTS article from the tutorial page is broken. Reading all of this tutorial is strongly advised. Note that admins desiring to use HTTP Public Key Pinning should thoroughly read through all precautions.
Securing your webserver with SSL/TLS | Ars Technica
How to obtain and install an SSL/TLS certificate, for free | Ars Technica
Certificates and security | Official Ubuntu 12.04 Server Guide
Qualys SSL Labs SSL Server Test
Weak Diffie-Hellman and the Logjam Attack
Rackspace nameservers by datacenter - Note that each datacenter has both two IPv4 addresses and two IPv6 addresses. To find the IPv6 address, do a reverse DNS check on each IPv4 address, then use host on each returned result to see the IPv6 address for the server.