How to: Move your NginX website to HTTPs / SSL

How to: Move your NginX website to HTTPs / SSL

It comes at no surprise that a lot of people are looking into moving their sites to HTTPs due to recent events: Google’s decision to give ranking points to sites that use SSL / HTTPs and eavesdropping by governments world wide. There are a number of considerations before taking this step, specially for people who have not yet deployed HTTPs / SSL on their web servers.

There are a number of things you need to start doing and fixing in order to have a functional site that performs well. Because most sites were not thought to use SSL to begin with, you’ll find that there might be problems when accessing your site from https instead of http. Below are a few tips to consider although it is not an exhaustive list:

1. Internal links: If you are using WordPress you will find a lot of the links you have not only do they include http:// but also the domain name. This is a problem for two reasons: 1) you are hard coding the transport (in this case http) so even if you use a different transport it will force the browser to take the hard coded one and 2) You are hard coding your site’s URL. Imagine you change your domain name… now you have to change all your URLs. For these reasons I generally recommend people use relative URLs (they start with / vs the transport or domain name).
2. Infrastructure concerns: Make sure your CDN supports SSL as well as any other part of your infrastructure (reverse proxies, firewalls, etc). Consider using SPDY when using SSL for added performance benefits. I really like using http://spdycheck.org/ to check for SPDY readiness. It lets you know if you have deployed SPDY and other tips to get the most out of it. We will go over the checklist for this in a minute
3. NginX specific configuration: We will cover the required configuration needed to address the implementation of an SSL site as well as performance considerations.

So let’s get to it!

I. Use SSL cache

As you can imagine hosting a site using SSL requires additional work on the CPU. We need to make sure we don’t saturate the CPU otherwise our site will be loading much slower. For example, I once tried using a 16k bit certificate… my CPU would die depending on the number of requests it had to handle. For that reason I’ve joined the 99% of people in using a 2k bit certificate for my site. For that same reason we need to turn on SSL session cache on NginX to save on CPU resources:

Don’t forget that the includeSubdomains should only be used if you are deploying Strict Transport Security to your subdomains as well. You can remove it if you don’t want your subdomains to use HSTS.

UPDATE: SSLLabs recommends using at least 180 days for your HSTS. So you should use 15552000 for max age once your done testing and find the performance of your site acceptable.

g) Enable OCSP Stapling

If you are not sure what OCSP Stapling is, I recommend reading the CloudFlare article: OCSP Stapling: How CloudFlare Just Made SSL 30% Faster. Pretty much what this does is remove a large portion of the SSL overhead by doing some work on your server. This is good as your visitors will enjoy a faster experience on your site.

First you need to make sure your certificate includes the entire certificate chain. I’ll look up a previous post I had on how to concatenate certificates to achieve this (pretty much you have your certificate and attach to it the certificates of each public certification authority above it.)

Here is the code needed on NginX:

ssl_stapling on;

ssl_stapling_verify on;

resolver 8.8.8.8 8.8.4.4 valid=300s;

resolver_timeout 10s;

Do keep in mind we are using Google’s resolvers for this. You can use other DNS resolvers if you prefer.

Here is a sample report from SPDYCheck.org:

Report Details