HTTPS Everywhere
September 6, 2015
HTTPS has been around for a long time, but until very recently it was reserved for privacy-sensitive sites such as those requiring authentication or accepting credit card payments. In the past couple of years, there has been a movement to use HTTPS for all web traffic.
Google is using HTTPS as a ranking signal, treating pages served via HTTPS as higher quality search results than those served via HTTP. The Chrome Security Team has proposed that HTTP pages be visibly marked as insecure. The Mozilla team has announced its plan to phase out support for HTTP in Firefox. While nothing similar has been announced for Safari, Apple has announced that it is deprecating the ability of iOS and Mac apps to make HTTP requests.
It is clear that the days of plain text HTTP are coming to an end.
I just updated my server so that it serves my sites via HTTPS. I have been dealing with SSL certificates and HTTPS configuration for years, but I was pleasantly surprised to learn of some options that make this transition easier and less expensive.
Servers with Multiple Certificates
At one time, configuring multiple HTTPS sites on a single server required that server have one IP address per certificate. This is no longer true. Server Name Indication alleviates this need by having the client report the hostname of the site to which it wants to connect. This is supported in most modern browsers, including versions of Internet Explorer since version 7 on Windows Vista or later.
Certificates for Multiple Hostnames
The server hosting this page is configured with one SSL certificate for twelve different hostnames across five different domain names. There is a rather old and well-supported extension to SSL called Subject Alternative Names (hat tip to Geoff Bradford), which allows a certificate to represent multiple hostnames. APE TEC provides a guide for generating a certificate signing request for such a certificate.
One downside to multi-hostname certificates is that the full list of hostnames is exposed to the client. Both Safari and Chrome on OS X show this information when you view the certificate. There are some circumstances in which you might not want to expose other hostnames in your SSL certificate: you might be hosting content for a customer whose relationship with you is under a non-disclosure agreement, or you might be hosting a placeholder page for an online service that you have not launched yet. If such a situation applies to you, a multi-hostname certificate for all of your sites may be a poor fit.
If you can use one SSL certificate for all of your sites, doing so will save you a significant amount of time and will simplify your server configuration.
Affordable SSL Certificates
The minimum cost of buying an SSL certificate trusted by modern browsers is now relatively low. NameCheap (affiliate link, hat tip to Daniel Jalkut via the Core Intuition Slack channel) sells single hostname certificates for $9/year (USD), multi-hostname certificates for just under $13/hostname/year, and wildcard (*.virtualsanity.com) certificates for $94/year.
Those prices are for Domain Verification certificates, in which NameCheap will only verify by email that you own the domain names for which you are requesting a certificate. NameCheap also sells Organization Validation and Extended Validation certificates for higher prices. Those certificates require more involved verification processes. If you are currently using HTTP, the Domain Verification certificates are probably adequate.
StartSSL (hat tip to Okke Timm via the Core Intuition Slack channel) offers free certificates, but does not allow those certificates to be used for commercial activities or for financial transactions.
Let's Encrypt is a free certificate authority that expects to launch in November of this year. I look forward to Let's Encrypt, but I do not think it is wise to wait for this launch. OS X 10.11 and iOS 9 will undoubtedly be released before November, and the Let's Encrypt launch date has already been delayed once.
Host Aliases
It is usually desirable to make your web content available at a domain name with and without the preceding “www.”. In addition, you may have registered common misspellings of a domain name, variations of a domain name with and without hyphens, and variations of a domain name within different top-level domains such as .com and .net.
Serving all of these aliases via HTTPS will add to the ongoing cost of hosting a site. Doing so is preferable, but you can economize by not serving HTTPS for all host aliases, and by redirecting HTTP requests received for the host aliases to the appropriate canonical HTTPS URLs.
Checklist
This is a checklist of items to remember when moving your sites from HTTP to HTTPS:
- Configure your server to issue 301 (permanent) redirects from HTTP to HTTPS.
- If you have an app that communicates with your server via HTTP, even if just for news updates or for software updates, test that the app handles the redirect properly. Update URLs in the app to use HTTPS.
- Update profile links in your social media accounts. This is not strictly necessary if you have redirects in place, but linking directly to your site via HTTPS will make following these links faster and more secure.
- If your server configuration already has some redirects, update those that redirect to HTTP URLs.
- Update any absolute URLs that might exist on your site. Remember links between sites that you host, canonical <link> elements, links in or to RSS feeds, and links in your sitemap.
- Test your sites with every browser that you support and also with curl.
- Configure your server to add a Strict-Transport-Security header to every HTTPS response. This will let the browser know that all connections to that host should take place via HTTPS.
Other Resources