given that LE takes just as much time and effort for
initial set-up as a standard multi-year cert
I think the LE endgame is that setting up HTTPS will be as easy as setting up SSH - i.e. every server will configure itself right on first launch and keep itself that way.
It's just going to take a long time to get there :)
> I think the LE endgame is that setting up HTTPS will be as easy as setting up SSH
It already is. Use a self-signed cert and ask your visitors via a side channel to tick the box to add an exception. That's the security model of SSH, and has the same assurances. It's just a terrible comparison. We can do better.
A better comparison would be with DNSSEC...
The way to simplify TLS deployment, while getting a better level security as DV CAs, would have been DANE. DNSSEC has an unfortunate reputation as being hard to setup ("pdnssec secure-zone mydomain" is not hard), but it also has exactly the same X day rollover key problem to solve as LE. Solving it once instead of twice would have made a lot of sense.
The symmetries between DNSSEC and LetsEncrypt are striking. Your account key is your KSK. Your cert is your ZSK... but instead of your webserver (in DNSSEC, your DNS server) doing rollover for you, you're depending on a pile of scripts, leaning on an already insecure DNS, and setting it up is still, comparatively, a pita.
The symmetries between DNSSEC and LetsEncrypt are striking. Your account key is your KSK. Your cert is your ZSK... but instead of your webserver (in DNSSEC, your DNS server) doing rollover for you, you're depending on a pile of scripts, leaning on an already insecure DNS, and setting it up is still, comparatively, a pita.
As the Caddy server linked in another comment shows, nothing in LE requires you to depend on a "pile of scripts" to do roll-over for you, it's just early days.
Yes, there will be products to make this simpler, but the point is, unless you are willing to grant LetsEncrypt a DV cert monopoly, to the exclusion of all others (or at least those not compatible with their API), then, in general, it can never be as easy as just turning it on.
DNSSEC puts the CA monopoly in the DNS. There is no API for a hypothetical web server using DANE, because there's no need for periodic domain validation. Of course, DNSSEC is a disaster, so it's a non-starter... but I'm still going to lament the fact that everything is terrible.
Since LetsEncrypt's API protocol is being standardized through the IETF (https://tools.ietf.org/html/draft-ietf-acme-acme), there's no reason any new competing free certificate providers can't be compatible with it. In the long term, if more show up (and I wouldn't be surprised if some existing CAs refocus their business on EV and start offering free DV certs through ACME), I see no problem with software giving the protocol a "monopoly", in the sense of building in auto-configuration support for it.
He was comparing the tls equivalent of how SSH works. First time you connect to an ssh server, you have to accept the host key, which most people do not (and in most situations, can not) verify.
It's just going to take a long time to get there :)