The Rise of The Free SSL Certificate
In this article I delve into how the SSL Certificate landscape has changed, and the trade-off between free+automated and expensive+manual.
SSL Certificates weren’t always free, you know?
They once cost a fair chunk of cash , had long, mandatory minimum expiry times in the range of years rather than months with costs ranging into the thousands.
The certification process was more involved too, with some authorities requiring you confirm your business address and legitimacy, physically!
These days your cloud provider or LetsEncrypt will give you never-ending certificates for FREE! So what happened? How and why did the industry shift?
First Things First
Let’s take a step back to review what SSL/TLS infrastructure looks like.
SSL (Secure Sockets Layer) & Private Key Infrastructure (PKI) is the technology behind the familiar URL protocol:
HTTPS://my-secure-domain.com/
This connection ensures not only that your data is encrypted in transit to the server, but also that you’re communicating with the party you expect.
It achieves this through a certificate signing process which involves a Root CA (Certificate Authority) which has the responsibility of creating certificates for a given entity (a web server, usually) which are signed by it. At the same time, this Root CA has its “client side certs” already (check it out!) embedded inside your Operating System and/or web browser.
Say you’re Bob, and Bob loves using Chrome to visit their favourite website,
https://www.google.com
Google’s web-server has a certificate installed which is served up on port 443 to Bob, signed by [Some CA named Z]. Bob’s Chrome Browser has an embedded certificate installed which was created by [Some CA named Z], this certificate is able to verify that the server is authentic, because the certificate it possesses was signed by an authority which has verified the ownership of the domain and the server.
This connection relationship is largely about trust. The Chrome browser’s client cert trusts ANY certificate signed by the same CA. So long as it has not expired or been revoked.
The connection will not be established (gracefully) without these factors being satisfied. (Effective encryption can still take place with self-signed certs - but a warning is issued because a trust relationship between client and server cannot be established)
With a properly working SSL connection, we achieve:
Authenticity about the server we are communicating with. (The server’s cert was signed by an authority we implicitly trust)
Encryption-in-transit from the browser to the server. (But not necessarily beyond these termination points)
There’s a lot more going on, of course, but these are the broad-strokes.
A key feature of certificates is the concept of EXPIRY. Over time, things change, and it makes sense to control the validity timeframe of any certificate which has been signed by an authority.
If a server’s certificate has expired, then the client will issue a serious warning… and generally break the UX and frighten the user (as it probably should)
Sounds Pricey…
With all this complexity, authority and signing going on - Root CA’s were billing their customers for certificates which lasted anywhere from 1-10 years. Upon expiry, a new cert would be issued, payment made, and the cert would be (manually) installed into the server infrastructure.
And this is still going on, and there are some valid use-cases for this workflow.
However, many cited frustrations over this convoluted process and the costs involved, and questioned the ivory-tower style market dominance of these Root CA’s.
After all… isn’t it just a client cert embedded in every web browser and a back-end which does signing of new certs? Simple stuff!
Hello, LetsEncrypt
Once LetsEncrypt’s cert was embedded in all major clients (browsers), there was nothing stopping them from handing out free SSL certificates to the world.
The only thing you really need to prove is that you own the infrastructure (domain/server) upon which the SSL certificate is going to be hosted.
CertBot handles the negotiation process with the CA, and you can get your brand-new cert delivered & installed in a fully automated way.
And it’s a good thing that it’s fully automated, because LetsEncrypt’s certs only last for 90 days, from the date of issue. And there is rate-limiting in place to prevent continuous renewals.
So each year, your web facing service needs to perform an automated renewal process approx. 4 times to install certificates across your infrastructure. Previously this process would occur roughly once every 24 months, or longer.
I can ascertain from personal experience, that the process of fetching, installing, verifying a certificate and reloading web-servers is not always perfect or risk-free. So you’re going to want to set-up some kind of SSL certificate monitoring across your fleet to ensure that, your certs are not getting too close to expiry, and that the new cert has been installed properly.
Trade-offs, as far as the eye can see
When you consider the amount of “DevOpsy” work which needs to happen to maintain a fully automated, monitored & stable FREE certificate refresh pipeline, you might ask yourself; is it actually cheaper than shelling out for a traditional certificate every few years?
It probably depends on your infrastructure and maturity of automation and testing.
Some certificates require embedding into devices or applications which are hermetically sealed and shipped.
Some applications may not be able to reach out to the internet to perform a renewal due to high-security and firewall infrastructure.
It’s also worth noting the rise of cloud services performing certificate management on behalf of their customers. Example, AWS’s ACM (Amazon Certificate Manager) which you can attach to a load-balancer, and forget about certificate renewal woes.
Takeaways
LetsEncrypt and ACM are great new options with short expiry times requiring frequent renewal.
The incumbents have not been displaced completely, there is a legitimate need for both styles of certificates and renewals styles.
Monitoring your certificates is required if you plan to automate renewals.
The effort and use-case for fully automating should be handled on a case-by-case basis.
- Daniel Korel
Great article. The other challenge with traditional cert providers and the costs associated is that most browsers no longer accept a cert that lasts more than a year or wildcards. Meaning the cost multiplies greatly.
I also love lets encrypt but companies ultra paranoid about security seem to not. I have run into several financial services and banking companies that will not allow a letsencrypt cert to be used. This gives the benefit to the cloud providers or vendors who have ACME compliant solutions like digicert or Cloudflare.