Why should I pay for an SSL certificate?eRr l0123dsaHCc T b I Nn Vv vr4le

9

I paid for an SSL certificate from Namecheap, I think it was certified by ComodoSSL. It cost me 7$, it took them a week to activate and I had to do it myself from SSH while editing my site's conf files.

Then a friend made me aware of Letsencrypt who not only give out free SSL certificates, but they can be installed by running a single command line.

I'm sure I'm missing something here, but why would I want to pay for an SSL certificate when I can get one installed easily, for free, with automatic renewal set up?

share|improve this question
  • 2
    This popped up recently and is mostly the same question: security.stackexchange.com/questions/45491/… The previously validated answer recently updated still mostly holds. But in all the answers I am sad to see noone explaining differences between prices and costs and price vs value (associated guarantees and insurances - to be believed or not, etc.) – Patrick Mevzek 23 hours ago
  • I can see paying for one where there is a business case for the extended validation, etc. in order to have company name next to lock icon, etc. From a technical perspective there is no real reason to. – ivanivan 26 mins ago

4 Answers 4

active oldest votes
15

Why should I pay for an SSL certificate?

For most uses, there's no good reason to pay for them.
See the very bottom for a summary of the exceptions.

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 a public key and some identification (such as a domain name).
  • The private key, which allows the holder (and only the holder) to digitally sign messages in such a way that they can be verified using the above certificate.

If you want a certificate for yourdomain.com, you:

  • Create a private/public keypair, and keep the private part, well, private.
  • Ask a trustworthy third party ("CrediCorp") to create a certificate for yourdomain.com with your public key.
  • Prove in some way to CrediCorp that you actually own yourdomain.com.
  • Put the private key and the obtained 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 (proving 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 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, they managed to convince some people that CrediCorp are, indeed, trustworthy, and they will only issue certificates correctly.

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.

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.

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 possible to lock your domain to just CAs of your choosing using DNS-CAA. 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 DNS-CAA is not checked by browsers, only by issuing CAs. So a compromised CA could ignore this safeguard.)

    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 anyway). See also this question.

    For what it's worth: the StackExchange network, which this site is a part of, currently uses Let's Encrypt certificates. Most people would never notice this, and if they did I sincerely doubt if it would mean much to them.

  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 current and somewhat older versions of 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 and StartCom (former purveyor of free certificates). So if you think Let's Encrypt will screw up (or will be dropped for some other reason), not using them will prevent you from getting caught in the fall-out.

  4. Certificates employ 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 or sha-1 are now rejected by most browsers, so any certificate that works doesn't use these deprecated crypto primitives. 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 may be rewarded with a green URL bar or padlock 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 may look more legit. The disappointment is, users rarely pay attention to them, so their effectiveness is limited. An attacker with a forged DV certificate can still impersonate the site, just without the extra visual clue an EV certificate may offer.

    So if you're a financial institution, you probably still 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 a limited 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. 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 DNS-CAA as well).

If none of those apply to you, feel free to not pay for your certificates.

share|improve this answer
New contributor
marcelm is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
  • 2
    Note that EV certificates are no longer considered useful because users ignore them; browsers, especially Chrome and on mobile devices, are removing or burying the green text and display of the name. – simpleuser 6 hours ago
  • 1
    Please keep in mind that you don't ask the trustworthy third party to create a certificate for your private key, but rather for the corresponding public key. Minor nitpick, but important. Your private key never leaves your system. – MechMK1 1 hour ago
  • Both good points; I was trying to manage the level of detail while still being correct in a big-picture way, but I should have been clearer on these two things. I updated the answer to hopefully reflect these facts a bit better. – marcelm 59 mins ago
5

Let's Encrypt is superior in many ways, including the ones that you have mentioned, such as:

  1. It's free. Hard to get past that.
  2. It has automatic renewal (I'm sure it's not JUST exclusive with Let's Encrypt, however)
  3. It's pretty easy to set up.
  4. Google supports it as a signed SSL, which is a huge deal when it comes to SEO and security.

However, there are a couple of cons.

  1. The verification system that it works on to make sure that, you, well, own the site, is not compatible with some website hosts, I have had a fair amount of headache trying to get Let's Encrypt work on InfinityFree and I just accepted the fate that I couldn't do it.
  2. You don't get any kind of insurance that says "If this breaks, we'll help you out" since it's open-source, you are on your own if Let's Encrypt doesn't work or is somehow cracked.
share|improve this answer
  • "The verification system that it works" It is a standard mechanism, both HTTP-01 and DNS-01 as described by IETF and CAB Forum requirements. All CAs are bound to the exact same one, for DV certificates. – Patrick Mevzek 23 hours ago
  • 4
    "since it's open-source" It is free (as in beer) not opensource. The API is standard (see ACME in IETF) and there are open source clients (and maybe servers). – Patrick Mevzek 23 hours ago
  • "It has automatic renewal" It is not Let's Encrypt by tiself. You, as the certificate owner has to contact them to ask for renewal. They do not push it to you automatically. It is a side effect of using an automated protocol such as ACME for certificate issuances. – Patrick Mevzek 23 hours ago
  • "Google supports it as a signed SSL," not just Google and you probably wanted to say that it supports it (Let's Encrypt) as a "fully trusted CA" ("signed SSL" is not meaningful). See letsencrypt.org/2018/08/06/… – Patrick Mevzek 23 hours ago
  • As for insurance on X.509 certificates used for HTTPS communications, see also security.stackexchange.com/questions/179415/… and scotthelme.co.uk/… – Patrick Mevzek 23 hours ago
2

LetsEncrypt certificates are great. I use them myself instead of buying certificates. There are a few drawbacks:

  • LetsEncrypt certificates only last 3 months. Most purchased certificates are good for one or two years. That means that you absolutely need an automated process in place to renew your certificates or it is going to be too easy to forget.
  • LetsEncrypt only offer the lowest validation type of certificate. Domain Validation (DV) only validates that the owner of the certificate has control over the domain. Organization Validation (OV) certificates also check the documentation of the person or company requesting the certificate. Extended Validation (EV) certificates require even further checks. The better your certificate, the harder it is to be forged, and the more your site's authenticity can be trusted because of it. In practice, browsers only give a visual nod to EV certs, usually showing something in green in the address bar for them. Up to this point, most users don't know or care about the different validation levels.
  • Wild card certificates are a bit harder to obtain from LetsEncrypt. From other places you generally just pay more money. LetsEncrypt requires DNS validation for wildcard certificates.

Historically, security certificates have always cost something. Other companies that have offered free certificates have come and gone. I used to use StartSSL which offered a single domain free certificate until they did some shady stuff and browsers stopped trusting their certificates. LetsEncrypt has fewer limits than previous free certificate vendors and is far more automated. It also has some big supporters such as the EFF, Mozilla, Chrome, and Cisco. See https://letsencrypt.org/sponsors/ It appears to be well enough run that I expect it to be around for years.

share|improve this answer
  • Is there any actual functional difference between DV and OF/EV? Or is it literally just a more thorough check? – Eight yesterday
  • 1
    "LetsEncrypt certificates only last 3 months." it is done on purpose and not seen as a drawback but a positive things in fact. – Patrick Mevzek 23 hours ago
  • @Eight Different checks and different end results too: a DV certificate identify an hostname, an OV/EV certificate identify an entity. Also CAB Forum requirements put different constraints, you can not have an EV for 3 years for example, nor for wildcards. – Patrick Mevzek 23 hours ago
  • "LetsEncrypt only offer the lowest validation type of certificate. [..] The better your certificate, the more your site can be trusted." This is hugely a matter of personal preference and not an universal truth. And it mostly does not matter because of the current Web PKI it is the security of the lowest secured CA in your trust store that defines the security of the whole ecosystem.. until everyone uses CAA+DNSSEC on their domains, and all CAs use at least DNSSEC during validation and multiple vantage points. – Patrick Mevzek 23 hours ago
  • @Eight At some points browsers also started to display website with EV certificate differently. Which does not change anything how they work under, they use the exact same cryptographic materials, primitives and algorithms than any other certificates, including DV and OV ones. – Patrick Mevzek 23 hours ago
-1

The simple answer to this is many webmasters just don't want to do these things which unnecessarily consume their precious time. In case of letsencrypt its easy to use and free but you have to remember and re-install the certificate every 3 months. If you don't or just forget to do it then you site will show 404 error to your visitors and search engines.

share|improve this answer
New contributor
Paul is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
  • 3
    "you have to remember " No, you need to put in place the needed automation and let it do its job without having anything to remember. You must also do monitoring. – Patrick Mevzek 23 hours ago
  • 5
    "it then you site will show 404 error " Certainly not. An expired certificate will trigger a TLS handshake failure and nothing will arrive at the HTTP level. Clients will see a big warning in their browser with some text (that they will basically not understand) and a button asking them if they want to go through or not. – Patrick Mevzek 23 hours ago

Your Answer

Thanks for contributing an answer to Webmasters Stack Exchange!

  • Please be sure to answer the question. Provide details and share your research!

But avoid

  • Asking for help, clarification, or responding to other answers.
  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged https security-certificate or ask your own question.

Popular posts from this blog

ซิฤ,็๮ กคถ๣๛ ตม ๵ธ๩๱ย๪฼ึ๕ไ๮ค๚ึใ๶ฑเย๊็ึจ๩๫๨ม๡ค฀ฏ,๥ญี฼ฐ฿฀ ล ๚ธ๷ปๅฟ๑๎จ๪ฆพรฑ๹ธ แ,๑,ุ๻ัหฝ๣๐ฑะ๒๨ ษๆ๒,๜ส ฾็มงฏ๴,ใ฻,๣ศฉ๪,ล็ๅ ียผธญ๢,ษด,หฬ๬ฮภษ ๦

ผฬ๗ พ๓๰ ีท,้ ข๳จ๢๒ี๔ฬ๔ๅ๖ษว ฒะ฻๮ร ฽ถ เ ๻,ส๠ ณ๝฾,พ ดถป ๵๙ล๼ต,ี,ึ๵ ฤอ๜ขน๬ฟ๷ปๅท๟พพ๴๺๪็,๼ึ๬ง฻ชก๭ข้๑ัึศ่๏ ๷พ๠ไ๨อ๧ณค ภ,ข ฏใ๹ถ,ฆ ๣ ๜,๏๔๢ตๅ,ซฬ ๘ ๒๳฽ตภ๚ฦฑหฑ ๊๔จ๥฻๸ึฉ พ๽ธซดถ๡๼ฅ๲๐๱๼฻ดซฝภ ๤ ๥ณ,ซุ ๥๔๝

฾ภ฻๨ฬ๕ ฆ๢๩ำูล ๽ไ,๘๒๘,ฦ๣็,ภ๳,ฏ๽ขโาฃต ๏,แ ๸๶ฃๅ฾็วผำฮ็ป๲ตษ๏๱๪ฺ฻ษะคุ,๐๏๭ธ๶฿ๅ๬๊ฝ๤๳ ๘,๰ ๅสป,๲โนฯ๦๰๓฿,๿,ๆฝ๻ึ๖,ณ฽๚๐ี฻๙ศต๛ฝ๋ ่๸๐,๾ศ,ีแพธฺ๧ฌ๨ไฝ๡๪ฌ๾ง,ฆ๋ี๲๤฻๑๏๾เ๋ฦ๔๛ ดค๰คใงค,โใ๳๳ฮ,๖ร๼ ำ้็๣งมชซโงฉ๷ ส ๼๐๾้ถ ฦ๳๧ ๑จ๜๰