An A+ HTTPS site for $20

After the CEO of an Internet Security company “explained” that it didn’t matter that his company website was only accessible using insecure HTTP (“it’s only marketing pages so we don’t need security”), I decided to build out a new website: https://WhyTLS.com. Here, I’ll be making my case that all websites need to move to HTTPS, and providing links and resources to help site owners do so.

Naturally, I needed to use HTTPS for my site, but my current host already has a certificate for a different hostname, and changing the site to use a multi-domain certificate would be an expensive hassle. Fortunately, I have recently started migrating my domain registrations over to Namecheap, and it turns out that they offer a great deal on their first year of hosting and HTTPS; adding these to my order was as simple as clicking two buttons.

So, for under $20, I’m now the proud owner of a new HTTPS-secured site.

When I bought a certificate for my old site, it was a bit of a pain—I had to create an account with a Certificate Authority and do some complicated dances to prove my ownership of the domain. I then had to give the hosting company $20 to “install” my new certificate on the domain, and pay them the same amount each time I renewed to a new certificate.

Fortunately, Namecheap’s integrated process was much simpler—the form to obtain the certificate was on Namecheap’s Control Panel, and was completely pre-filled out except for “Job Title”, “Company” and “Phone Number” fields (the CA wanted these). With the click of two buttons and a wait of about 10 minutes, I got email telling me that my certificate was ready to install. I clicked “Activate” in the Control Panel and my HTTPS site was live!

I immediately headed over to SSLLabs.com’s Server Test to see how the security of my site measures up. It got an “A”, beating the “B” my other site gets (that one is hindered by running on Windows Server 2008, which only supports older ciphers). Now, an A is good, but I want an A+. That’s easy—I just need to add a HTTP Strict Transport Security (HSTS) policy to combat SSLStripping attacks.

Using my editor, I created /www/.htaccess and added the following lines:

RewriteEngine on
# force ssl
RewriteCond     %{SERVER_PORT} ^80$
RewriteRule     ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]
# Send HSTS policy
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS

I saved the file, and here we go– A+ HTTPS configuration, with minimal hassle, for under $20.

Now, is it perfect?

No. Let’s take a closer look at the SSLLabs report.

SNI Required

At the top, there’s a small banner: . I’ve written about SNI before but SSLLabs’ “Handshake Simulation” report shows exactly what this means: My site will show a certificate error on Android 2.3, IE on Windows XP, and with Java 6, none of which support SNI.

The SNI TLS handshake extension allows a web hosting provider to cut costs by hosting multiple unrelated sites at a single IP address; without receiving the extension from the client, the server doesn’t know which certificate to return.

Fortunately for me, these platforms are fading in importance and I have the luxury of ignoring them. Or so I thought. I later tried to set up WebDAV support on this server so I could use Windows Explorer to manage its files and I found the SNI extension was not getting sent by the SvcHost process:

This bug was supposedly fixed in Windows 8.1, but my results here show otherwise; the problem was fixed in Windows 10 and Microsoft is looking at bringing the fix downlevel.

Extra Certificates

The configuration contains one other minor problem – it sends one certificate more than necessary in the certificate chain sent when the client connects:

The “Contains anchor” notice means that the server sent to the client the root Certificate Authority certificate:

This is an small waste of precious bandwidth, because either the client already has this certificate in its Trusted Root store, or the connection will fail anyway (because a client isn’t going to start trusting the root just because the server sent it). Note: There are some obscure cases (related to Extended Validation EV certificates) where sending a root may be useful to help a client recognize the certificate should get the “green bar” EV UI treatment, but those doesn’t apply here.

I’m excited to see that deployment of HTTPS is getting easier with each passing month, and I’m very much looking forward to the launch of the Let’s Encrypt project (certificates free of hassle and cost) later this year.

-Eric Lawrence