There is lots of talk at the moment about internet security – hacking, compromised accounts, lost financial information, identity theft.  The question is “how can you give confidence to your users so that they can trust the web site they’re visiting?” (ie. “yours”).  One critical part of that answer is “HTTPS” - securing your web site with an SSL Certificate to ensure that the data transmitted between your browser, and a web-site you’re visiting is encrypted end-to-end.  So … LetsEncrypt – it’s SSL For Everyone !

Part One (this post) provides an introduces to SSL Encryption, in particular the features of on of the free services that provides free, trusted, SSL Certificates … LetsEncrypt.  Part Two (future post) will cover how to install it and use it on your site.

Why Encrypt?

Answer: To data safe while it’s “in-transit” between the client and your server.  Because it’s a Good Thingâ„¢

What kind of data is being encrypted with you enable SSL / HTTPS on your site?  The answer is “everything” … if you choose to.  That little caveat is important – some sites chose to only encrypt certain information, often for performance reasons (there is some overhead to encryption).  For example they might choose to only encrypt text content, or use it for the submission function when posting data back to the web server; but not encrypt static content such as images.

My own recommendation - encrypt everything!  Yes, there is an overhead, but there are new protocols (or new versions of existing protocols) out to help with this, and if your site is being hit by sufficient volumes of requests, you’re probably looking at a service that offloads the overhead of processing SSL-encrypted requests, for example using a load balancer.  But such design and infrastructure architecture discussions are all for a different post!

There is all sorts of information transmitted between your browser and the destination server, often information that you do not want “visible” to anyone snooping on the network.  For example:

• Usernames
• Passwords
• Bank Account and Credit Card Details
• Passport / Social Security / National Identity Details

It is this sensitive information that you want to ensure cannot be intercepted during transmission, nor can it be modified in any way.

But I’m not a Big Organisation …

Even if you’re not running a bank or online store, your user’s personal details are valuable and sensitive information.  By encrypting your site, you are helping to protect them from risks such as financial loss, or identity fraud.  You are also protecting yourself as an administrator … do you really want your administrative credentials to be compromised by an unauthorised person?

So - even as a humble blogger with no associated online store, by enabling SSL on your server, you are telling your users that you value their security, and you recognise the importance of having integrity in their connectivity to your site!

Where to get an SSL certificate?

To get an SSL Certificate, you need to request one from a “Certificate Authority”.  These are entities who issue digital certificates.  They share specific information to the developers of (for example) web browsers.  This information is known as a “trusted root signing certificate”.  This information tells your browser who can be trusted to sign new SSL Certificates – if it trusts the signer, then it also will trust the web site certificate(s) that are signed by it.

There are a number of commercial organisations who are trusted to sign SSL Certificate requests, these “Certificate Authorities”, such as Comodo, Symantec, GlobalSign offer SSL Certificates – usually at a cost.

There are other CAs  which offer free certificates, but are not necessarily trusted – for example CACert – the infrastructure and process is there to create the certificates, the problem is that unless action is taken in advance to forcibly trust the CA root signing certificate, then users will receive errors that prevent them from easily browsing your site.

A third option is to sign your own Certificate – this is known as a “Self-Signed” certificate.  These are not recommended for most use-cases, as they are signed by a CA that is not “trusted” by anyone - your browser will create an error and in the first instance prevent you from viewing a site… as per

Not all SSL Certificates are created equally

In terms of SSL Certificates from trusted Certificate Authorities, you might wonder “what is the difference between the different types of SSL Certificates?” – and it’s a good question, because there are differences.

At their core, all SSL Certificates are the same – they offer the same key function – to encrypt communications between 2 end-points.  Where they differ is in the level of trust you can associate with the SSL Certificate.  The different types of SSL Certificates  are described below.

Domain Validated (DV) Certificates

Domain Validated SSL Certificates can be considered the “entry-level” form of SSL Certificate.  It allows you to be sure that you are connecting to, and receiving content from, the web site that you requested.  These certificates are issued based on proving ownership of the domain, and that the domain is valid.  There is no need to provide any additional form of proof.

They are used to secure the communications between your client and your web server, but do not offer any additional level of trust/protection.

Organization Validation (OV) SSL Certificates

Organisation Validation SSL Certificates are only issued to Companies once there has been verification of some company information as well as verifying domain ownership.

The benefit above Domain  Validation Certificates is that it not only encrypts the data, but there is an additional level of verification of the company that owns the web site, which improves the trust of the relationship

Extended Validation (EV) SSL Certificates

Extended Validation SSL Certificates are the “highest level” of SSL Certificate available.  Before they are issued, there is a strong review process involved – validating and verifying the validity of the details of the company.

Like the Organisation Validation Certificates, Extended Validation Certificates both encrypt the communication and improve the trust in the relationship between client and server, by reviewing and validating the company requesting the new certificate.  Where they differ is in the level of diligence and applied to the review and verification process.

Browsers recognise a web site protected by an EV certificate and notify a user by using a “green” Address Bar in modern browsers while viewing the site – something that cannot be triggered by a DV or OV Certificate.

Other Benefits

One other benefit from high levels of SSL Certificates (EV over OV over DV Certificates), is the level of warranty provided.  EV Certificates from commercial CAs offer significantly higher insurance over OV which in turn offers higher insurance than DV Certificates

What is means is that if the CA fails to properly validate the information contained within an issued SSL Certificate, and if that failure results in an end-user losing money in connection with a fraudulent online credit card transaction, then the end-user may have a claim to recovery of this loss from the Certificate Authority.

Many Options

As discussed above, there are clearly many options for obtaining SSL Certificates.  My own personal choice is to use LetsEncrypt – it provides free Domain Verified SSL Certificates, and is a Certificate Authority that is trusted by most modern browsers.

I do not suggest that using an OV or EV Certificate is not appropriate for your use-case, they are not bad or incorrect  choices.  However for many individuals I talk to, for many use-cases, DV certificates provide the core function required by the site administrators, and by their clients…  This is simply one man’s preferences; an articulation of “why”, and later, some details on “how-to”.

At the heart of things however, is the importance of encryption – it increases trust, secures data in transit, and overall “Just Makes Sense” ™  OV and EV Certificates serve to improve on that trust.  So please, by all means use your own preferred Certificate Authority!… just encrypt!

The rest of this post, and the pending “Part 2” – will focus mainly on “LetsEncrypt”.

Introducing LetsEncrypt

LetsEncrypt is about making SSL Certificates available for everyone, everywhere – to make the internet a more secure and safer place!  And – it does it at no cost!

Established in 2016, LetsEncrypt is a Certificate Authority that provides free SSL Certificates for Transport Layer Security (TLS) encryption.  It’s actually a very clever system.  The SSL Certificates are short-lived – they only last 90 days, but to counter-act this, they are automatically renewed!  The process used by LetsEncrypt ensures that the service being protected by one of its certificates is contactable and verifiable using a combination of DNS lookups and service connections (eg. connecting to the web server to be protected).

90 Days is awfully short!

Many may argue that 90 days is too short, however the developers of LetsEncrypt have demonstrated that a 90-day certificate lifetime is actually quite common quoting 29% of TLS transactions as using a 90-day certificate. there are however 2 specific drivers for using such a short expiration period (remember, previously many would use a 1 or 2 year certificate)

1. It limits the damage through key compromise and mis-issuance by ensuring that such keys are only valid for a limited period
2. It drives automation – which is an absolutely critical element of “encrypting everything” and driving the adoption of HTTPS everywhere!

No more expiring SSL certificates

I can’t even begin to count the number of times one of my customers has had a service outage due to expiring certificates.  There are some very public examples of this happening, due (for example) to an organisation forgetting to renew their SSL Certificate.

The automation approach employed by LetsEncrypt avoids this problem entirely.  There are some considerations in terms of timing for updating SSL Certificates, but once installed, the process is automatic!  You can even get yourself sent some reminders if the renewal fails!

Reduced cost

It’s increasingly rare for organisations to only have a single domain name. Heck, I’m not even an organisation and I have 14 – either for myself, or I host them for friends (yes, I did just pause to go and verify the number!).  I’ve had more though – 27 at last count, and that’s just the ones that I have purchased through @Blacknight !

If I were to purchase a commercial SSL Certificate for each of these domains, and for each of the services that I run (eg. Web, Mail) then I could be looking at a considerable amount of money. Yes – there are free Certificates Authorities (CAs) such as CACert, however they don’t do away with the need to renew, and there are also “trust issues”.  (Incidentally, I’m both a Personal as well as an Organisational Assurer for CACert – or at least I was… it’s been a while since I’ve been asked to assure someone).

Trust

As mentioned above, “Trust” is an important item when browsing the internet, and in particular when it comes to encrypting web sites.  How do you know you can trust the web site you’re visiting?  Can you be sure that the connection between you and the site you’re browsing has not been intercepted (ie. “Man-In-The-Middle” attack).

In many ways, it all boils down to DNS (ie. proof of ownership of the domain), and the integrity of all the related transactions.

• What is the Fully Qualified Domain Name (FQDN) of the web site you’re visiting? (eg. example.com)
• Does the “Name” stored in the SSL Certificate presented by a server match the FQDN that was requested?
• Is the SSL Certificate still valid (eg. has it expired)?
• Does your web browser trust the Certificate Authority who signed the SSL Certificate?

This last step is important.  Who is allowed to sign SSL Certificates?  And on what basis do they do so.

LetsEncrypt does this essentially on the basis of “Domain Ownership”.  The certificates are Domain Validation Certificates – if your service uses a domain name (eg. web server, email server, etc), and if supports the TLS protocol, you can use it!  Note that email encryption is a different protocol that is not supported by LetsEncrypt.

On the basis that you have administrative access to the domain, administrative access to install and setup the LetsEncrypt software, administrative access to modify the service (eg. web server) configuration files necessary to enable SSL, then the LetsEncrypt “engine” then does a series of tests to verify that it can connect and validate the one-time credentials that are established for this test … if this test fails, you do NOT get an SSL Certificate installed.

I’m Sold … What next?

So – hopefully, if you’re read this far, you’re in agreement that SSL is a Good Thingâ„¢.  The next step is doing something about it – this is where Part 2 of this blog post comes into play – it will provide details on how to install and then use LetsEncrypt.

Stay Tuned for Part 2 !