I love LE and I think it's the least worst solution. But mandating CA TLS into a protocol is very bad for human use cases. HTTP+HTTPS prevents this fragility. HTTP/3 with it baked in is fragile.
Also, you don't need DNS to communicate with an IP.
I love LE and I think it's the least worst solution. But mandating CA TLS into a protocol is very bad for human use cases. HTTP+HTTPS prevents this fragility. HTTP/3 with it baked in is fragile.
Also, you don't need DNS to communicate with an IP.
You're right that DNS isn't architecturally analogous to TLS. The way it's analogous is that if the central infrastructure goes away, then people have to do something more technical than usual to get things working again. Yes, using an IP address string in place of a hostname is simpler than setting up an alternate CA, but broadly it's the same idea, a centralized dependency with an inconvenient workaround.
I'm not surprised the flagship certbot automagically handled the deprecation since you apparently consistently update it. But many setups, especially those without auto-updates and other moving parts, just stopped working. And certbot would've too if you hadn't have made sure it was up to date. And some acme clients never supported 2 and just died. It will happen again.
>a centralized dependency with an inconvenient workaround.
Except there's no workaround with QUIC based HTTP/3 because all the libs people use come without the flags to allow self signed certs. So 99% of browsers/HTTP using software released is stuck with CA TLS or no communication at all.
It doesn't matter if you set up a custom CA for internal use or if you enable it in your custom http/3 lib build of your custom build of $browser. People still won't be able to visit your hosted HTTP/3 site with your custom CA. Not without you installing your root cert in the browser or system cert store of most people on Earth. That seems unlikely to happen.