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.
Apple iOS devices have application icons for the app on three different device types (iPhone, iPad, and iPad Pro), the store, spotlight (search), settings, and notifications, and these icons may need to be provided in single (unadorned), double (“@2x”), or triple (“@3x”) scale factors.
Android icon requirements had remained fairly consistent, but as of Android 8.0 (Oreo, API 26), those application icons are now classified as “legacy”, though still required for support on earlier devices (i.e., 85.4% of the market); the latest devices can use “adaptive” icons. All applications should have a store icon.