Is there a reason to use an SSL certificate other than Let's Encrypt's free SSL?
Solution 1:
Certificate lifespan
Security
Shorter lifespan is better. Simply because revocation is mostly theoretical, in practice it cannot be relied on (big weakness in the public PKI ecosystem).
Management
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-user impression
End-users are unlikely to have any idea one way or another.
Level of verification
Security
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).
Management
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-user impression
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.
Installation
Security
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.
Management
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.
End-user impression
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.
Overall
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.
Solution 2:
From a purely technical perspective:
- The fact that the certificates are only valid for 3 months. Can be a nuisance to maintain depending on your change management procedures and infrastructure.
- The purpose of Let's Encrypt certificates is limited. You can't use them for your email, code signing or timestamping.
Check with:openssl x509 -in cert.pem -noout -textX509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
From an end-user perspective:
- The lack of Extended Validation means "no green bar" in certain webbrowsers.
- However, Chrome will be phasing out the green bar in September 2018 in favor of a small lock icon and eventually no special indicator and will instead only show warnings for insecure pages.
Solution 3:
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.
Solution 4:
There are two groups of downsides worth considering.
1. Downsides to using the Let's Encrypt service
Let's Encrypt requires that the exact name, or the (sub-)domain if you're requesting a wildcard, exists in the public Internet DNS. Even if you prove control over example.com, Let's Encrypt won't issue you certificates for some.other.name.in.example.com without seeing that in public DNS. The machines named needn't have public address records, they can be firewalled off, or even physically disconnected, but the public DNS name needs to exist.
Let's Encrypt certificate lifetimes of 90 days mean you need to automate because ain't nobody got time for that. This is in fact the intent of the service - to herd people towards automating this essential work rather than perversely doing it manually while they automate away many harder tasks. But if you can't automate for any reason it's a negative - if you have tools, appliances or whatever that block automation consider any commercial SSL cert costs as part of the ongoing cost of those tools/ appliances/ whatever in cost planning. Contrariwise offset savings from not needing to buy commercial certs in pricing of new tools / appliances / etcetera that automate this (with Let's Encrypt or not)
The Let's Encrypt proof of control automation may not suit your organisation's rules. For example if you have employees who're allowed to reconfigure Apache but shouldn't get SSL certs for company domain names then Let's Encrypt is a poor fit. Note that in this case just not using them is the Wrong Thing(TM) you should use CAA to explicitly disable Let's Encrypt for your domains.
If Let's Encrypt policy refuses you, the only "court of appeal" is to ask in its public forums and hope one of their staff is able to offer a way forward. This may happen if, for example, your site has a DNS name their systems decide is "confusingly similar" to certain famous properties like big banks or Google. For sensible reasons the exact policies of each public CA in this regard are not open to public scrutiny so you may only realise you can't have a Let's Encrypt cert when you request it and get a "Policy forbids..." response.
2. Downsides to a Let's Encrypt certificate itself
Let's Encrypt certificates are trusted by major web browsers today via ISRG (the charity providing the Let's Encrypt service) but older systems trust Let's Encrypt via IdenTrust, a relatively obscure Certificate Authority which controls "DST Root CA X3". This gets the job done for most people, but it isn't the most broadly trusted root in the world. For example the abandoned Nintendo WiiU console had a web browser, obviously Nintendo won't be shipping updates for WiiU and so that browser is abandoned, it doesn't trust Let's Encrypt.
Let's Encrypt only issues certificates for the Web PKI - servers with Internet names which use the SSL/TLS protocol. So that's the Web obviously, and your IMAP, SMTP, some types of VPN server, dozens of things, but not everything. In particular Let's Encrypt doesn't offer certificates at all for S/MIME (a way to encrypt email at rest, rather than just when it's in transit) nor for code signing or document signing. If you want a "one stop shop" for certificates, this may be enough reason not to use Let's Encrypt.
Even in the Web PKI, Let's Encrypt offers only "DV" certificates, meaning any details about yourself or your organisation other than FQDNs aren't mentioned in the certificate. Even if you write them into a CSR they're just discarded. This may be a blocker for some specialist applications.
Let's Encrypt automation means you're constrained exactly by what the automation allows even if there is no other reasons why you can't have something. New types of public key, new X.509 extensions and other additions have to be explicitly enabled by Let's Encrypt on their own timeline, and of course you can't just offer to pay extra to get the features you want although donations are welcome.
Nevertheless, for almost everyone, almost always, Let's Encrypt is a good first choice for putting certificates on your TLS servers in a fire-and-forget way. Starting with the assumption that you'll use Let's Encrypt is a sensible way to approach this decision.
Solution 5:
I'll add one that forced my employer partly away from Lets Encrypt: the API rate limiting. Due to the short lifetimes and lack of wildcard support, it is very easy to come close to the rate limits during normal automated operations (automatic renew, etc.). Trying to add a new subdomain can push you over the rate limit, and LE has no way to manually override the limit once hit. If you don't back up the old certificates (who would do so in an automated, cloud-type microservices environment like LE envisions?) all of the affected sites go offline as LE won't reissue the certificates.
When we realized what happened, there was a moment of "oh $#!#" followed by an emergency commercial certificate requisition just to get the production sites back online. One with a more reasonable 1 year lifespan. Until LE implements proper wildcard support (and even then), we're going to be very wary of their offerings.
Tl;dr: LE wildcard + API limits makes managing something more complex than "My Personal Homepage" unexpectedly challenging, and promotes poor security practice along the way.