You have probably heard of Secure Sockets Layer or SSL as it’s known in its acronymic form. SSL is essentially what allows websites or web applications to be served on https:// rather than http://. SSL actually has an updated replacement, Transport Layer Security, known as TLS. However, many people have just stuck with the term SSL to describe secure certificates in general.
I’m not going to go into the details of how TLS certificates work in this blog post, but if you are interested a good place to start is my colleagues blog post, Who Should You Trust? A Secure Certificate Architecture On The Web. I’ve also recently come across https://tls.ulfheim.net/ which illustrates a TLS connection rather nicely.
Historically, SSL certificates would be applied to your website or web application but only enforced on specific pages where users may exchange data with the website (server). Ordinarily these were pages such as login pages, or payment checkout pages, where users would be entering sensitive information such passwords or card details. Generally, you would browse websites without SSL and occasionally find the odd exception. The reason it was often implemented in this way was because:
a. people didn’t see the need to protect non-personal data being relayed between the user and the server, and
b. it was seen as an unnecessary performance overhead on the server itself.
HTTPS Everywhere
Several years ago, Google went on a crusade to try and get webmasters to update their entire websites to use SSL with the ultimate goal of protecting users from websites that didn’t treat personal data with the level of security it deserves. To do this, Google indicated that whether a website used SSL would be a factor in where the website ranks, with non SSL sites being pushed down in search results.
More recently, in July 2018, Google Chrome (version 68) started to mark websites as ‘not secure’ should no SSL certificate be available, and in version 69 of the browser Google has now removed the ‘Secure’ wording from the browser when a site with a valid SSL certificate. Ultimately Google want SSL to be the norm and the exception to be non-SSL.
Other browsers have understandably followed suit and implemented their own rules which more or less fall in line with Google’s overall plan.
The not so new kid on the block
You might think that SSL certificate providers would be rubbing their hands together based on this, and for the immediate future they may well be. However, there are alternatives to purchasing SSL certificates, including a reasonably well-known certificate authority called Let’s Encrypt. Let’s Encrypt was formed in 2014 and has a number of major sponsors and donors who are backing the project to help provide free SSL certificates.
Let’s Encrypt has killed two birds with one stone. Not only do they provide free certificates, but also, they have encouraged the automation of SSL certificate provision and implementation. Certificates only last 3 months, which whilst on the face of it doesn’t seem practical compared to the usual 1-2-year shelf life of a paid for certificate, is actually more secure and when combined with an automated renewal process makes the issue irrelevant.
By their very nature, the web applications that we develop hold data which is often highly critical to the organisation. For all of the web applications we develop and host, we provide an SSL certificate as standard -something we have done for a number of years. We now default to providing our clients with Let’s Encrypt certificates to ensure the web applications we develop for them remain secure with the added benefit of having one less recurring cost that needs to be incurred for the privilege.
