Is there a reason to use an SSL certificate other than Let's Encrypt's free SSL?

Let's Encrypt are providing free SSL certificates. Are there any downsides compared to other, paid certificates e.g. AWS Certificate Manager?

4 Answers
4

Shorter lifespan is better. Simply because revocation is mostly theoretical, in practice it cannot be relied on (big weakness in the public PKI ecosystem).

Without automation: Longer lifespan is more convenient. LE may not be feasible if you, for whatever reason, cannot automate the certificate management

With automation: Lifespan doesn't matter.

End-users are unlikely to have any idea one way or another.

Letsencrypt provides DV level of verification only.

Buying a cert you get whatever you pay for (starting at DV, with the same level of assertion as with LE).

DV = only domain name control is verified.

OV = owner entity (organization) information is verified in addition.

EV = more thorough version of OV, which has traditionally been awarded with the "green bar" (but the "green bar" appears to be going away soon).

When using LE, the work you put in is setting up the necessary automation (in this context, to prove domain control). How much work that is will depend on your environment.

When buying a cert the DV/OV/EV level will define how much manual work will be required to get the cert. For DV it typically boils down going through a wizard paying and copy/pasting something or clicking something, for OV and EV you can pretty much count on needing to be contacted separately to do additional steps to confirm your identity.

End-users probably recognize the current EV "green bar" (which is going away), other than that they don't tend to actually look at the certificate contents.

Theoretically, though, it is clearly more helpful with a certificate that states information about the controlling entity. But browsers (or other client applications) need to start actually showing this in a useful way before that has any effect for the typical user.

It is possible to do things incorrectly in ways that expose private keys or similar.
With LE, the provided tooling is set up around reasonable practices.

With a person who knows what they are doing, manual steps can obviously also be done securely.

LE is very much intended to have all processes automated, their service is entirely API-based and the short lifespan also reflects how everything is centered around automation.

When buying a cert, even with a CA that provides APIs to regular customers (not really the norm at this point) it will be difficult to properly automate anything other than DV and with DV you are paying for essentially the same thing that LE provides.

If you are going for OV or EV levels, you can probably only partially automate the process.

If the installation is done correctly, the end-user will obviously not know how it was done. The chances of messing things up (eg, forgetting to renew or doing the installation incorrectly when renewing) are less with an automated process.

Traditional means of buying certs are particularly useful if you desire OV/EV certs, are not automating certificate management or want certs used in some other context than HTTPS.

From a purely technical perspective:

openssl x509 -in cert.pem -noout -text

X509v3 Extended Key Usage:

TLS Web Server Authentication, TLS Web Client Authentication

From an end-user perspective:

I'd like to offer some counter points for the arguments used against Let's Encrypt here.

Short lifetime

Yes, they have a short lifetime as explained in the faq: https://letsencrypt.org/2015/11/09/why-90-days.html To quote the page:

They limit damage from key compromise and mis-issuance. Stolen keys and mis-issued certificates are valid for a shorter period of time.

They encourage automation, which is absolutely essential for ease-of-use. If we’re going to move the entire Web to HTTPS, we can’t
continue to expect system administrators to manually handle renewals.
Once issuance and renewal are automated, shorter lifetimes won’t be
any less convenient than longer ones.

Lack of EV

There is no plan for EV support. The reasoning (from https://community.letsencrypt.org/t/plans-for-extended-validation/409) is:

We expect that Let’s Encrypt won’t support EV, because the EV process will always require human effort, which will require paying someone. Our model is to issue certificates free of charge, which requires a level automation that doesn’t seem compatible with EV.

Furthermore there are some that believe that EV is harmful, like this blogpost (https://stripe.ian.sh/):

James Burton, for example, recently obtained an EV certificate for his company "Identity Verified". Unfortunately, users are simply not equipped to deal with the nuances of these entities, and this creates a significant vector for phishing.

A classic real world example of this is sslstrip. Homograph sites with legitimately purchased certificates are a real-world attack for which EV doesn't provide a sufficient defense currently.

Unless you need a certificate for something other than web, there are no real downsides, but surely perceived ones. Although the problems are only perceived, as the owner of a website you may have no other choice but to address them (if business interest forbids showing the middle finger).

The single biggest downside is, for the time being, that your site will show as somewhat inferior, maybe dangerous because it doesn't have the nice green badge that some other sites have. What does that badge mean? Nothing, really. But it does suggest that your site is "secure" (some browsers even use that exact word). Alas, users are people, and people are stupid. One or the other will take your site as not trustworthy (without understanding any of the implications) just because the browser doesn't say it's secure.

If ignoring these customers/visitors is a valid possibility, no problem. If you cannot afford that business-wise, you will have to spend money. No other option.

The other perceived problem is the one about certificate lifetime. But it is actually an advantage, not a disadvantage. Shorter validity means that certificates have to be updated more often, both server-side, and client-side, alright.

As for server-side, this happens with a cron job, so it's actually less hassle and more reliable than usual. No way you can forget, no way to be late, no way to accidentially do something wrong, no need to log in with an administrative account (... more than once). On the client-side, so what. Browsers update certificates all the time, it's no biggie. The user doesn't even know it happens. There's very slightly more traffic to be had when updating every 3 months instead of every 2 years, but seriously... that is not an issue.

cron

web

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.