How To Get Free SSL Certificates

The whole internet basically runs off certificates these days. They're the backbone of modern encryption. If you want to run a service on the internet then you're going to need an SSL certificate to do that. That, or browsers are going to flag your website as "not secure". The problem with certificates is that they're confusing, they cost money, and then they expire and you need to do it all over again. But what if they were free? And what if they renewed themselves? Enter Let's Encrypt.

Let's answer the obvious question first: What is an SSL certificate? SSL stands for Secure Sockets Layer. It has been replaced by TLS or Transport Layer Security. Basically TLS 1 is SSL 4.

It's the new version but we still tend to refer to certificates as SSL certificates.

These certificates provide a way for your computer to verify the identity of a service over the internet and establish an encrypted connection to them. If you're watching YouTube in a web browser, go to your address bar and click on the padlock icon. There should be an option to view the certificate. That is a certificate that proves that the YouTube website is really YouTube, and allows you to use it securely.

As to how exactly certificates work... I'm not going to get into that right now because that's a whole topic by itself. I'm pretty sure someone's commented asking me about that before, though; so if that's something you want me to cover then drop a message in the comments. The more of you who ask, the sooner i'll get around to doing it. For now, just know that any website worth their salt uses an SSL certificate, and that is just the tip of the iceberg.

Websites are the most visible example because there's literally a button you can click to see the certificate; but virtually all electronic data transmission these days is using certificates.

Why we need certificate authorities

So what's special about these certificates? Why can't I just make my own? Well, you can. It's pretty easy. You can make your own certificate and have it last for as long as you want. The problem is that nobody will trust it. It's a bit like me drawing a medical degree on a piece of paper. I can make one. I can make a paper certificate that says I'm a surgeon, but nobody's going to let me operate on them because that piece of paper has not been endorsed by a recognized medical school.

SSL certificates are kind of the same. They all need to be endorsed by someone. If i could make an SSL certificate without any checks or balances then I could make one saying my website is Google, and that would undermine the very purpose of certificates.

In order for your device to trust a certificate it has to be signed by an organisation that your device already knows it can trust. I could make my own Google certificate myself, and sign it myself, but your device just wouldn't trust it. What this means in practice is that if you want to use a certificate on the internet you need to get it signed by a recognised public certificate authority. Depending on where you get them they could cost less than one hundred pounds a year, or more than a thousand for a single domain name. Although you'd need to have a really good reason to pay that much for a single name certificate - that is straight up robbery!

Certificate expiry

You'll notice I said "per-year". Certificates have a finite lifespan. They're stamped with an end date and once that date passes they're no longer trusted. There are a couple of reasons for this. One is if someone impersonates you by way of a stolen or dodgy certificate, there's only a certain length of time they can try to use it for. The other is that if a technical flaw is found in the technology, new certificate standards can be released and the old ones will naturally fall out of use, whether their owners bother to update or not. The problem is that this validity period keeps getting shorter in the name of improved security. It used to be ten years, then it was five, then it was two...

Technically I think it's still officially two years, but practically speaking a bunch of browser makers have banded together and said they won't trust certificates with a duration of more than one year. So in reality the maximum duration is now one year. You might be able to buy one for longer, but there's no point if browsers won't trust it.

What this means is that administrators find themselves needing to install certificates more and more often. Not only are they being used in more places than ever before as all communication becomes encrypted, but they also need to be renewed ten times as frequently as they used to, in each of those places. So how difficult is this?

I'm going to say something that might be controversial here... I don't think it's that difficult, but I know a lot of people struggle with it; and when I say a lot of people, I mean a LOT. It is insane how many problems result from botched certificate renewals. i saw a stat that said 74% of organisations experience outages because of expiring certificates. Even Microsoft Reams was down earlier this year because of one.

I don't think that renewing a certificate is that complicated. At least not individually. What is a problem is that every single application seems to use a different frigging process. Seriously, just in my lab i have 10 services that use a certificate, and every one of them has a different installation process. Why!?

This is probably a big part of the reason people mess them up, and the other is that the ever-increasing volume of renewals is just causing administrators to drop balls. So if a certificate authority came along and said that they'd only sign certificates for a maximum of 90 days, you can't imagine many people would want to use them... right? You'd be wrong.

Let's Encrypt

Let's Encrypt does just that, and it's incredibly popular. Fundamentally, Let's Encrypt is a different approach to traditional certificate renewals. The Let's Encrypt certificates are completely free, and they are advocating the use of free software to automate the renewals for you. The short duration is basically a risk mitigation in case someone discovers a flaw in the automation; and if it's completely automated then the duration doesn't actually matter, does it?

Let's Encrypt is a non-profit with the backing of some of the biggest players in tech, including the likes of Mozilla, Cisco, Google, Facebook, Amazon, Red Hat, VMware, IBM... Honestly, it would probably be quicker if I listed the ones who aren't direct sponsors. Microsoft. No, wait, Microsoft owns Facebook and Facebook sponsors Let's Encrypt. OK, everyone supports Let's Encrypt!

The goal of Let's Encrypt is simple: make the internet a safer place for everyone by encrypting everything. Barriers to this are cost and effort, so Let's Encrypt gives the tech away for free and tries to as much of the work for you as possible. Does it work? Yeah. Sort of. Let's Encrypt is awesome for web servers. There are plugins for most of them that make it dead easy to install a certificate and then have it renew automatically. If you host websites, stop paying for certificates. Stop renewing certificates. Use Let's Encrypt - it's basically a no-brainer.

That by itself covers a huge portion of the internet. The problem comes with things that aren't standard websites, like the majority of your typical corporate systems, for example. Remember my lab - those 10 applications? One of them is Apache. That's dead easy. Install Certbot and you're away. The rest of them don't have any automation I can just slap in. That means I'm back to manual installations, except now i need to do it every 90 days. So switching to Let's Encrypt takes my lab from 10 installations per year to about 36. If that were the end of the story I wouldn't have switched my lab over to Let's Encrypt, now would I?

Just because there isn't a ready-made plugin doesn't mean you can't automate it yourself. I'm not going to lie. This can be quite a pain to get working, and some vendors don't provide any way to change certificates other than pointing and clicking through a graphical interface; but they are the exception. Most applications can be automated if you put the effort in.

On Linux you usually just need to know where to put the certificate files, what permissions to assign, and what to restart. With Microsoft there are usually PowerShell commands to deal with the certificates, and that means you can script it. There are some vendors who just don't give you any programmatic access at all, but if you look at online feature requests basically every vendor is getting flooded with requests to support Let's Encrypt; and some are actively working on baking it into their products. I expect to see more and more support for this in the future - even if it's not native Let's Encrypt support and just API access to go and write the automation yourself.

Where we're at now is that if we're talking about a typical website on Apache, NGINX, or IIS; then you should really be doing this. If it's a more complicated system that isn't natively supported then most companies are sticking to the tried and tested manual certificate renewals, rather than writing their own automation.

They're looking at it like this: we can pay a few hundred quid for a certificate that we know how to install, or we could take a risk and get the certificate for free, but the time we'd spend trying to automate it will cost more than just buying a certificate that we know works. It doesn't add up, or does it?

If you just look at the cost of the certificate the business case doesn't look that compelling; but what about the cost of an outage because you missed a renewal? Remember, 74% of organisations are getting bitten by this. Let's Encrypt's 90-day validity basically requires you to automate; but now that a paid certificate only lasts for a year anyway and you likely need to renew in a ton of places each time, I would argue that the case for automation is starting to stack up anyway; and if you're going to automate you may as well use Let's Encrypt because it's free and they've done a lot of the work for you.

Further information

Certbot is one of the tools for automating your renewals. It started out as the official Let's Encrypt client. Ownership has been transferred, but it's still free, it's still open source, and you can think of it as the official reference implementation. Certbot works great with open source, and it does work on Windows, but you may find other clients with native support for IIS or PowerShell to be a better choice for that ecosystem. There are lots of options with different niches and you might find something that integrates better with your specific use case than Certbot does.

• Let's Encrypt: https://letsencrypt.org/
• CertBot: https://certbot.eff.org/
• List of Let's Encrypt (ACME) Clients: https://letsencrypt.org/docs/client-options/

I'm running my lab automation with PowerShell, so I initially opted for a PowerShell-based Let's Encrypt client; but then the maintainers stopped supporting it and I had to rewrite some of the automation. This time i'm going with Certbot because although it doesn't have the direct integration, I know that as the semi-official client it's always going to be around. I know some of you were probably hoping I'd give you a step-by-step tutorial rather than a link, but go look at the link.

There are a ton of different clients you can use and lots of different applications you can integrate them with. Which combination should I do the tutorial on? If I do a step-by-step it will help a fraction of you, as long as the process never changes. If I point you at the information then it can help all of you, all of the time. That's my thought process, anyway. "Teach a man to fish", as they say; and now you know what you're looking for, you can find an in-depth tutorial if you want one. My goal here wasn't to solve every single problem for every single scenario. It was to signpost what's possible.

If you want a deeper article to explain how certificates actually work, let me know in the comments. If you've used Let's Encrypt, what's the most interesting system you've automated? If you haven't used Let's Encrypt but you're going to, then come back and share how it went.

Let's encourage each other with real-life stories so people can stop paying and start automating.