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.
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:
- 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.
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.
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”.
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)
- ItÂ limits the damage through key compromiseÂ and mis-issuance by ensuring thatÂ such keys are only valid for a limited period
- 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!
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).
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 !