# Why should I pay for an SSL certificate?
**You probably shouldn't, nowadays.** See the very bottom for a summary of the few reasons why you might want to.
Let's take a step back and explain what certificates do and roughly how.
What are commonly called "certificates" consist of two linked pieces:
- The _certificate_ proper, which contains some information (such as a domain name).
- The _private key_, which allows the holder to digitally sign messages in such a way that they can be verified by anyone having the certificate.
If you want a certificate for `yourdomain.com`, you:
- Create a private key.
- Ask a trustworthy third party ("CrediCorp") to create a certificate matching your private key for `yourdomain.com`.
- Prove to CrediCorp that you actually own `yourdomain.com`.
- Put the private key (and certificate) on your server, and configure the web server to use them.
Then, if Alice visits `yourdomain.com`, her browser gets the certificate from your web server, along with a message signed by your private key. Then her browser checks three things:
- That the signed message can be verified by your certificate (guaranteeing it's been signed by the corresponding private key that only `yourdomain.com` should have).
- That the certificate's domain is the domain the browser is trying to visit (`yourdomain.com`).
- That the certificate is from CrediCorp.
The combination of these three things guarantees Alice that she actually is talking to `yourdomain.com`, and not to some impostor, _provided that Alice trusts CrediCorp_. (There also follows some [crypto voodoo](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange) to turn this authenticity into confidentiality.)
# How _does_ Alice trust CrediCorp?
That's the real crux here. In short, at some point CrediCorp said "Hey, we're going to make certificates". After putting in a lot of effort following [a lot of rules](https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.5.pdf), they managed to convince some people that CrediCorp are, indeed, trustworthy.
In particular, they managed to convince the makers of, say, Firefox. As a result, CrediCorp gets on Firefox' A-list, and their certificates are trusted by Firefox by default. So really, Alice trusts Firefox, Firefox trusts CrediCorp, and CrediCorp trusted (after verifying) you when you claimed you owned `yourdomain.com`. It's almost like a [chain](https://en.wikipedia.org/wiki/Chain_of_trust).
But, Firefox doesn't just trust CrediCorp to issue certificates for `yourdomain.com`, it trusts CrediCorp certificates for _any_ domain. And Firefox _also_ trusts ShabbyCorp, for any domain.
This has consequences. If someone manages to convince ShabbyCorp that they own `yourdomain.com` (because ShabbyCorp isn't very thorough), then they can obtain a ShabbyCorp certificate for `yourdomain.com` with corresponding private key. And with that certificate they could impersonate your web server. After all, they have a certificate (plus key) for `yourdomain.com` that is trusted by Firefox!
CrediCorp and ShabbyCorp are what's called Certificate Authorities, CAs for short. In the real world, ComodoSSL and Let's Encrypt are examples of CAs. But there's a lot more of them; as of this writing, [Firefox trusts 154 CAs](https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport).
# Whoa. But how does that answer my question?
I'm ehm, getting to that...
Here's the thing. The mechanics I outlined above apply to all certificates. If you have a correct, trusted certificate for your website, it'll work. There isn't anything special about Brand A certificates versus Brand B certificates; they're all subject to the same CA requirements, and the same crypto math.
And even if you like CrediCorp better — because you know, they just sound so much more trustworthy — using them won't really help you. If an attacker can convince ShabbyCorp to give them a certificate for your site, the attacker can use that certificate to impersonate your site, regardless of where you got yours.
As long as Firefox trusts ShabbyCorp, visitors won't see the difference. (Yes, they can pull up the certificate, and dig through there, see who issued it. But who does that?) As far as forging certificates is concerned, this makes the entire system as weak as the weakest of 150+ CAs. Yes, that _is_ a bit scary, and it's probably the biggest criticism of this entire scheme. Still, it's what we're stuck with.
Point is, if you don't trust a CA to give out "good" certificates, not using that CA doesn't help you.
# Gotcha, everything is equally doomed. No caveats?
Weeeelllll...
1. Let's start with killing the point I made in the last section. Nowadays it is sort of possible to [lock your domain to just CAs of your choosing](https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization). Suppose that you do trust Comodo, and don't trust Let's Encrypt, it is possible to ask non-Comodo CAs not to issue certificates for your domain. In theory (because CAA is not checked by browsers, only by CAs).
The question then is, is Let's Encrypt actually less trustworthy? Or less secure? Trustworthiness is a hard one, how do you quantify that? All I can say is that _in my perception_ Let's Encrypt is no less trustworthy than other CAs. As for the security of their validations, they are very similar to what commercial CA's do (for DV certificates, see below). See also [this question](https://security.stackexchange.com/questions/87443/what-makes-lets-encrypt-secure).
2. For a certificate to be meaningful, the issuing CA must be trusted by software vendors, otherwise the certificate is useless. I used Firefox as an example, but really you want the CA to be trusted by at least Firefox, Chrome, Windows, Mac OS X, iOS, and Android. And the dozens of smaller players. This is the case for any CA normal people would consider, including ComodoSSL and Let's Encrypt.
3. If a CA misbehaves, or is revealed as untrustworthy, it will get removed from the various trust stores quickly enough to ruin the day of certificate owners. Two notable examples I know of are [DigiNotar](https://en.wikipedia.org/wiki/DigiNotar) and [StartCom](https://en.wikipedia.org/wiki/StartCom) (former purveyor of free certificates). So if you think Let's Encrypt will screw up, not using them will protect your site from such fall-out.
4. Certificates contain some crypto math magic; the question is _which_ crypto math magic? What if it's weak magic? This is actually a real concern, and CAs have shown to drag their feet on upgrading this, too. Luckily, browser vendors have picked up the slack by setting minimums here for certificates to be accepted. For example, certificates using [rsa-1024](https://blog.mozilla.org/security/2014/09/08/phasing-out-certificates-with-1024-bit-rsa-keys/) or [sha-1](https://knowledge.digicert.com/generalinformation/INFO3977.html) are now rejected by most browsers. The upshot is, it's pretty hard for any CA (Let's Encrypt included) to disappoint on _this_ part anymore.
5. Before I said more or less that all certificates are created equal. I lied, they're not. In particular, what I discussed up until now are "Domain Validated (DV) certificates", which is what the vast majority of websites use. They prove, more or less, that your browser is talking to the domain it shows in the URL bar. There are also "Organization Validated (OV)" and "Extended Validation (EV)" certificates, which require much more elaborate checks from CAs. In particular, you should only be able to get an EV certificate for `somebank.com` / SomeBank Inc., if you can actually prove you _are_ SomeBank, Inc.
EV certificates are a lot more costly to obtain, and they are usually rewarded with a green URL bar in the browser, maybe displaying "SomeBank, Inc." as well. Contrary to DV certificates, they also offer some guarantee as to who the website might actually belong to. The upside is, they look more legit. The disappointment is, users rarely pay attention to them. An attacker with a forged DV certificate can still impersonate the site, just not with the green URL bar.
So if you're a bank or something, you probably really want an EV certificate. For most things, it's overkill. But if you do need EV, Let's Encrypt isn't for you because they simply don't offer EV certificates.
6. Certificates are only valid for some period of time. Certificates from a typical commercial CA tend to be valid for one year, but I've seen two or three years as well. Let's Encrypt certificates, on the other hand, are only valid for three months, so you'll need to replace them more often. For Let's Encrypt users, this is usually automated, so certificates are replaced every two months.
Being able to do that with widely available software is actually more pleasant than the yearly _Oh shit my certificate expired? What's my login at the CA? How does this work again?_ ritual that most small sites end up with at commercial CAs.
7. And finally, there's other benefits a paid CA might offer, such as support, or a [million-dollar SSL warranty](https://scotthelme.co.uk/do-ssl-warranties-protect-you-as-much-as-rocks-keep-tigers-away/). I have little faith in both of these aspects, but they are things that Let's Encrypt does not offer.
# My head hurts... I had a question I think?
Use what you feel comfortable with! For DV certificates, there is little that actually differentiates the various CA's. I use Let's Encrypt both privately and professionally, and I'm happy with it.
There really are only thee potential reasons I see to avoid Let's Encrypt:
- If you need EV (or OV) certificates.
- If you can't or don't want to automate certificate renewal and three months certificate validity is too short for you.
- If you don't trust Let's Encrypt (but be sure to consider other measures like CAA as well).
If none of those apply to you, feel free to not pay for your certificates.