In January I wrote about our plans in moving Yoast.com to SSL. We’ve since done that, with great results from an SEO perspective: we had no negative effect on traffic, whatsoever. Two weeks ago, we also moved our tool Quix to https. There are quite a few things we learned in the process of moving these two sites to SSL that we thought would be worth sharing with all of you. Also, some things happened in the last few weeks that make SSL a hot topic, so we’ll discuss those first.
Ranking benefit for completely SSL sites?
Last month, Search Engine Land reported that Matt Cutts had said about SSL that he’d “personally love to make it part of the ranking algorithm”. The Wall Street Journal picked up on this two days ago. Whether or not this actually happens (or, perhaps, has already happened) doesn’t really make much of a difference to me. A completely SSL site looks more trustworthy than a non-SSL one [reference needed].
From a spam fighting perspective I think I can see why Matt would like it. I don’t think many spam network creators would go through the hassle of setting up SSL for all their sites and buying certificates for all of them. The cost would soon become higher than the profit in many niches.
Heartbleed
The recent Heartbleed debacle (if you don’t know what it is, read this and / or this simple explanation) showed us once again how vulnerable the web can be. The good thing about it is that when you think about people being able to “listen” to your web traffic, you suddenly realize it might actually make sense to encrypt a whole lot more of it.
Moving your site to https
In moving yoast.com completely to https / SSL we figured out there’s a few things you need to be aware of:
- All of your internal links should start to use https, not just to pages, but for images, JavaScript, CSS, etc. This means going through your theme with a fine comb and cleaning all of those up. Of course you can have your web server redirect http to https (more on that below), but not having to do the redirect is a lot cheaper.
- Your CDN needs to support SSL too. Of course, we use and love MaxCDN and they can set up SSL for your CDN subdomain very easily.
- SPDY, a networking protocol primarily developed by Google that you can enable for SSL traffic, is awesome. It makes your website faster and funnily enough that means that your fully SSLed site could actually be faster for those people who visit your site with modern browsers than your plain http site.
- Not all SSL setups are equally safe. Once you’ve set up your site with SSL, it’s important to then make a conscious decision about how safe you want your traffic to be and act on that, more below.
You will need a static and unique IP for your site. This is “logical” if you know how SSL works, but it also means that most shared hosting servers won’t allow you to do this.– As mentioned by David in the comments: if your server supports Server Name Indication you don’t even need a dedicated IP.
https & SSL Web server config
Because yoast.com is hosted on Synthesis, we didn’t have to do much to allow for SSL with full support for SPDY, as they took care of all the details for that, which is only part of the reason we love them. For Quixapp.com we had to do it ourselves, which meant re-compiling our NGINX with SPDY support and a few more bits and bobs. For most people it’s probably a better choice to either go with a smart hosting provider like Synthesis or hire someone to do this for you. If you’re not sure whether your current setup supports SPDY, you can use spdycheck.org to check, or simply type spdy in Quix.
We did tweak our setup quite a bit though, as SSL can require more resources on your server and not setting it up properly could lead to load issues and delays. Below are the specific lines from our NGINX config related to the SSL session cache:
ssl_session_cache shared:SSL:20m; ssl_session_timeout 10m;
The next thing to tweak are the available ciphers. If you’re implementing this, I’d suggest referring to this article about hardening your web servers SSL ciphers as it explains in detail some of the settings below. That article is kept up to date so it’s better to check that than the code below, but for reference, this is what we currently use on yoast.com:
ssl_prefer_server_ciphers On; ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;
Add-on: OCSP Stapling
In the comments there was a question from Jesin about whether we’d implemented OCSP stapling. We hadn’t, simply because I didn’t know what it was. I looked it up and saw several very positive mentions of the topic, for instance this CloudFlare post, so I implemented it straight away.
It means that you sent status info about your certificate along with the request, instead of making the browser check the certificate with the Certificate Authority. This removes a large portion of the SSL overhead, the CloudFlare post above explains it in more detail.
I used this guide, but it’s very easy, just add this to your NGINX config (this uses Google’s DNS for resolving and assumes your certificate file contains the entire certificate chain):
ssl_stapling on; ssl_stapling_verify on; resolver 8.8.8.8 8.8.4.4 valid=300s; resolver_timeout 10s;
Strict Transport Security header
One of the other cooler things you can do is add a Strict Transport Security header. This will force the browser to load all subsequent requests from the same host over https, even when you’ve linked to http.
In NGINX, you add this like this:
# This forces every request after this one to be over HTTPS add_header Strict-Transport-Security "max-age=31536000";
For other servers, including Apache, check the WikiPedia page on the Strict Transport Security header, more specifically the implementation section. Note that if you run subdomains, you could also add those, but unfortunately not ALL our subdomains are on SSL yet, so we haven’t been able to do that yet. Luckily, our friends at MaxCDN were nice enough to turn it on for us.
BTW if you’re wondering why I use MaxCDN, their new tools site shows nicely how fast the already blazing fast yoast.com is in comparison to cdn.yoast.com, which is running at rocket speed, compare the two here. That tool is pretty useful to compare two sites in speed.
SSL test
If you’ve done the above correctly, you should be able to pass the Qualys SSL test with flying colors, we sure do. If you use Quix, you can run that test on any domain simply by typing the command ssltest. I think you should aim for at least A in this test, though A+ is easily achievable when you add the above Strict Transport Security header.
Redirect from http to https
This last bit will help you tremendously when you’ve not updated every single link in your site yet. You can just add a straight server level redirect from http to https. In NGINX, we do this by having two servers defined in our config, the “right” one, that listens on port 443 and a simple one that listens on port 80 (normal http) and has just this:
server {
listen 80;
server_name yoast.com www.yoast.com;
return 301 https://yoast.com$request_uri;
}
This seems to be the fastest way of doing this in NGINX, in Apache you’d do something like this:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
What type of SSL certificate should you get?
In my opinion, if you’re going to invest serious time in doing this, it’s only worth it when you make sure you get the maximum benefit. With Extended Validation certificates you get the green address bar, which is what you want:
If you think that’s expensive, think again. For instance here at Namecheap an EV SSL cert could cost you as little as $139 a year, so go for that but be sure to check their different offers if you have multiple domains. Of course if you’re cheap you could get just a domain validation certificate which would cost you like $9 a year.
So… Should you move your website to https?
If you’re a web shop or otherwise transactional website you probably already have SSL for your checkout. If so, moving your entire website to https makes a LOT of sense to me, it’s probably actually easier to maintain and makes sure that you’re doing everything to make sure your SSL traffic (and thus the most important section of your site) is as fast as possible.
If you’re a purely informational website you might not need to make the move, but if some of that information could be privacy sensitive, I think it’d be a good idea to implement SSL anyway.
Would love to hear your ideas on moving your website to https and SSL in the comments!
This post first appeared on Yoast. Whoopity Doo!