Hacker News Reader

Comment by jaas | Hacker News Reader

The reason we haven't announced an EOL for ACMEv1 is that we won't announce one until we are confident we won't cause the kind of meltdown you describe.

View on HN

You could block new domains (new to Lets Encrypt) from using v1.

This will break many tools which currently rely on LE. E.g. mailinabox, which uses LE to set itself up.

I doubt they would just break it. I imagine if they do this then this will be announced sufficiently in advance (probably around two or three years) to allow people to update their ACME clients. Then you can just operate the ACMEv1 for existing domains until noone is asking for more (and scale down the architecture).

The problem is that LE is being used as plumbing. I noticed MIAB was using LE because I recognise that SSL-out-of-the-box is something interesting, and I investigated. But I wager most people who use it will have no idea. They just install it, and "it works", as it should. great. What's HTTPS? That's the entire point of tools like MIAB, mind you:

> Technically, Mail-in-a-Box turns a fresh cloud computer into a working mail server. But you don’t need to be a technology expert to set it up.

https://mailinabox.email

I'm just choosing MIAB as an example here. This applies to anything that LE now enables. People don't know they're using LE, much like IOT users don't know they're using HTTP/1.1. It's part of the plumbing. What's an ACME client? What's LE? What's v1?

This is probably happening for IOT devices across the globe just the same. A 2y expiration date is an order of magnitude too low for plumbing. Imagine if we suddenly decided to phase out HTTP/1.1 within two years.

We have to recognise that we are shoving HTTPS down people's throats. Pretty soon, HTTP will get big f-off warnings. OK: fair enough. However, if we're doing that, we should also provide a viable alternative, with the same reliability. Otherwise, HTTPS is a massive step backwards for the decentralised web. LE is that alternative, but not if we start breaking backwards compatibility every 2 years.

Again, I'm not saying that the two year expiration date means "v1 stops working".

Rather, "after this point, no new domains may setup via v1", so any existing certificates and installations are grandfathered. Two years is sufficient for MIAB to update their software and distribute to users.

>LE is that alternative, but not if we start breaking backwards compatibility every 2 years.

Not what I'm saying either. They have a v2 now, we don't know if they need a v3. And they want to keep v1 running for a while.

But there will be a point where v1 will need to be switched off, similar to how modern browsers have switched off SSLv1 despite a lot of people still having servers running with that.

LE will, at some point, have to decide between keeping v1 running or moving away from old protocols to be able to evolve. And that cannot be infinitely pushed backwards.

That's good to know, thank you for the info.

You might simplify things for yourself to some extent by requiring ACMEv2 for wildcard requests, which will reduce the number of people deploying the old client and spur many to upgrade.

And your old client still works on the systems it's deployed on (by definition) so you could just stop development on that.

Wildcards are only available via ACMEv2. The post linked to here says that.

d'oh, I overlooked that (and I still had the post open in another window!). Thanks.

It's bad enough that some people comment without reading -- I apparently commented without paying attention.

Reply on news.ycombinator.com