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.
Welcome back to The Pro Tech Show - the place for tech, tips and advice for IT pros and decision-makers.
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 this on 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. 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! 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. Although, hang on, I'm recording
this in December 2020 but if it doesn't go live until 2021 then I'm talking about last year.
Now, 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 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! Do you know what else everyone should support?
This channel, by liking and subscribing. Oh man, that was pure YouTube cheese... OK, back to 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. I'm going to put some links in the description for you. Firstly, to Let's
Encrypt itself, and then the main link you probably want to look at is for Certbot. 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. I'll also put a link to the official list of other clients as well.
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. I'll put the links there so you can have a look. If you can't
decide then I'd recommend Certbot simply for the fact that it's not going anywhere. 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 video 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.
I'm going to bring this video to a close but I don't want you to feel like I'm abandoning you
to the cool darkness of the internet, so here are a couple more of my videos to keep you company.
If you found this useful, give it a like and don't forget to subscribe for future videos.
Thanks for watching, guys. See you next time!