Why I think Let's Encrypt won't be a threat to commercial CAs for now

April 16, 2016

One of the questions these days is what effects Let's Encrypt and their well publicized free TLS certificates will have on existing commercial CAs. While LE has become a very popular CA and there have been some amusing signs of nervousness from existing CAs, my personal belief is that Let's Encrypt is not going to be a threat to the business of commercial CAs for the medium term, say the next few years.

One reason I say this is pragmatic past history. LE is not the first or only free SSL CA, and that existing free SSL CA does not seem to have made any particularly large dent in the business of other CAs. Now, there are certainly some differences between LE and this other CA that makes this not quite an apples to apples situation; LE is very well known now and issues short-duration certificates through easy automation, while the other free CA is less well known and issues year long certificates through a more annoying and onerous web-based process that not everyone can take advantage of. However, I think it's still a sign of some things.

(The other free CA also charges for certificate revocation or early replacement, which did not endear them to a lot of people during Heartbleed.)

Beyond that, there are a number of potential reasons that Let's Encrypt certificates are not necessarily all that compelling for many organizations. In no particular order:

  • LE doesn't issue wild card certificates.
  • Even with their recently raised rate limits, 20 new certificates a week is still potentially a real limit for decent sized organizations (who can have a lot of hosts and subdomains they want TLS certificates for).
  • The short duration of LE certificates pretty much requires developing and deploying new automation to automatically renew and roll over LE certificates. With commercial CAs, a moderate sized place can just buy some certificates and be done for the next few years, with minimal staff time required.

    (At least some CAs will even mail you helpful reminder emails when your certificates are approaching their expiry times.)

Finally, as a commodity basic TLS DV certificates are already available for very little money. It's my impression that a lot of organizations are not that price sensitive about TLS certificates; they simply don't care that they could save $10 or $20 a year per certificate, because the aggregate savings are not worth thinking about at their size. They might as well go with whatever is either simpler for them now or already familiar. Let's Encrypt is compelling for the price sensitive hobbyist, but for a decent sized organization I think it's only interesting for now.

(And for a large organization, the rate limits probably make it infeasible to rely on LE for new certificates.)

However, I do expect this to change over the longer term. What will really threaten existing CAs is the addition of turn-key integration of LE certificates in more and more pieces of software. Once you can set an option in your web server of choice to automatically get and maintain LE certificates for each virtual host you have or add, I think that a lot of people in a lot of organizations will just turn that option on rather than wrestle with all of the little hassles of commercial CAs. Once LE becomes the easiest choice, existing CAs have much less to offer to anyone who fits into LE's rate limits (basically CAs are down to 'we'll sell you wild-carded DV certificates').

(I'm ignoring EV certificates as another thing entirely, but if CAs feel actively threatened by LE I expect them to start trying to push EV certificates much more strongly. One obvious danger sign would be if CAs start trying to persuade browser vendors to restrict certain JavaScript or browser capabilities to only EV-validated sites instead of all HTTPS sites.)

(This is sort of an elaboration of a comment I left on Tanguy Ortolo's entry about this issue (via Planet Debian).)

Written on 16 April 2016.
« Unbound illustrates the Unix manpage mistake with its ratelimits documentation
Why Unix needs a standard way to deal with the file durability problem »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Apr 16 01:04:29 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.