Adding SSL/HTTPS support to Apache.

You may have noticed (or not) that this blog has recently acquired a little padlock icon to indicate that it is “secure”.  You can now access the blog using “https://”; in fact, using “http://” (without the ‘s’) just redirects to the secure page anyway.

Marketing Purpose

This change has been on the task list for a very long time, but it finally became really important when, last July, Google changed Chrome to display “Not secure” next to any web site that did not have a certificate.  Given that Chrome now represents about 60% of browser usage across all platforms, that is not an audience we would ignore. Fortunately, at the moment, the little indicator in Chrome, and other small reminders in various browsers, are not too damaging, but this is likely just the beginning of more and more dire warnings.  Realistically, there is essentially nothing passed from this blog outside of Digital Gamecraft itself that needs to be encrypted, per se, but readers do not necessarily know that, and they should not be asked to know that, either. From a marketing standpoint, anything that causes a “customer” (in this case, reader) to have to make a decision (e.g., “Is this site safe?“) reduces the likelihood that individual will continue, which means that it reduces the audience.  Not desirable.

Technical Purpose

In the past (i.e., when this task was first added to the web improvements list), adding support for secure, encrypted communication via SSL/TLS/HTTPS was a complicated and confusing process.  Frankly, this is why it never quite bubbled up to the top of the list and, thus, never got implemented until recently. Without getting too technical (because I could not, even if I wanted to), SSL stands for Secure Socket Layer, which is a protocol for encrypting communications, and TLS stands for Transport Layer Security, which is a newer version of the same thing.  TLS actually supersedes SSL, but the latter is still used generally to represent both SSL and TLS.  HTTPS is the protocol used to do the actual communication. The idea is that everything transmitted over the internet (such as this blog post), if not encrypted (i.e., using HTTP), is readable at every server and router along the way.  Encrypting the data makes this (nearly) impossible, so TLS (or SSL) is used, and HTTPS tells the receiving computer that the message needs to be decrypted.  The process of encrypting and decrypting data relies on certificates that need to be obtained from a certificate authority (CA), which is where things were most complicated. In the “old days” (just a few years ago), you would have to contact a CA to get a certificate, and this process often required providing lots of information to prove who you were before (always) paying an annual fee for a certificate.  There are different types of certificates with various levels of verification and you can still spend upwards of $500/year on a certificate, or even $150/year or so for certificates no better than certificates you can get for free.

Implementation

You read me correctly: FREE.  Over the past few years, the cost of low-end certificates (enough to be considered “secure”) has dropped to the point of now being free and automated.  In particular, Let’s Encrypt is a certificate authority “run for the public’s benefit” that provides free certificates. Additionally, the automation provided by Let’s Encrypt and EFF’s Certbot makes this fairly simple to do.  After the fact, knowing how easy this was, I am somewhat embarrassed that I did not do it sooner.  So, here is how I did it… I started at the Let’s Encrypt site, read a little bit, and then was directed to the Certbot site, which (on the main page) just asks for your web server and system type.  Caveat: We run our own servers here, so I have full shell access to the system; I do not know how much more difficult it may be trying to do this through a web interface. Because we are using Apache running on Ubuntu (Xenial) to serve this site, I ended up on this Certbot page.  First, I updated my system, just to start with the latest components, and then I just followed the (5) steps in the Install section.  If you have ever installed Linux software from a command line, the process should seem quite familiar. Next, I typed in the first command under Get Started:

sudo certbot --apache

I answered the few questions (asked only once) about, as I recall, contact information and whether I wanted to be added to the EFF mailing list (emphatically not).  The meat of the program produces a list of domains served by the Apache installation and allows you to select which ones you want to serve as HTTPS.  After that, it asks whether you want to redirect all HTTP traffic to HTTPS (recommended), which seems to be working flawlessly. In our case, we have quite a few domain and host names all serving one of a relatively small number of sites.  I initially did just one site (https://sophsoft.com), which worked a charm, but I ended up recreating that certificate and including all of the other host names that serve up the same pages (e.g., www.sophsoft.com and sophsoft.info).  I then repeated the process separately for each discrete site.  Voila!  Done. Actually, the installation process, when finished, gives you a link to SSL Labs testing page so you can verify the security of your page.  All of our pages were given Overall Rating: A. As noted in the Automating renewal section, the certificates are only good for 90 days (gift horse and all that), but it looks like there is a cron job that can be installed to automatically renew.  I admit that, until I started writing this paragraph, I thought that it had been installed already, but it looks like I will need to do that myself.

Final Adjustments

We did still have one or two pages (OK, the whole blog 🙁 ) that initially served up encrypted pages but still showed a broken padlock, indicating lack of security.  This can be caused by residual HTTP references in a page, which result in only portions of a page being secure.  Often, image links are still insecure, so they need to be fixed. In our case, the blog needed the canonical address to be updated to HTTPS in the settings, the custom theme had a reference to an image file accessed insecurely, and many of my actual blog posts made explicit HTTP image references.  It really only took a few minutes to find and fix the issues, but there was a little sleuthing involved.

Conclusion

Sooner or later, and I imagine sooner, web pages that are served up without encryption will be the outliers and will have an increasingly diminished reputation.  I would be quite surprised if Google’s search ranking algorithms did not already favor HTTPS pages.  Given that the cost has now dropped to nothing and automation makes the process pretty easy, it seems like an obvious improvement for any business that values its web presence.