4 ms·
ACME renewal feels less like a time bomb than traditional renewal, even though it happens more often. Showing manually-renewed certs expiring as evidence for wh
by jchw 1y ago
ACME renewal feels less like a time bomb than traditional renewal, even though it happens more often. Showing manually-renewed certs expiring as evidence for why ACME is a bad idea is literally completely backwards!
> My medical opinion: if it hurts, maybe you should stop doing it.
Funny enough, that's the exact opposite of the common wisdom for deployment:
> If it’s painful, do it often.
The idea is that if you were to wait months between deployments and do enormous deployments, there is a very good chance that you will have problems every time. First of all, if it's infrequent, you can tolerate things like downtime windows for deployment, which are unideal. Second of all, it batches tons of changes at once, which increases the chances you'll need to roll it all back. Thirdly, it makes it harder to even figure out what went wrong, since the problem-causing change could've gone in months ago.
By having ACME renewel happen very often, it should become apparent very quickly when they're not working, much closer to when you made the change that broke it. I believe this is an improvement full-stop. If you want it to work even better, add alerting when the certificate gets too old and monitoring/observability on the renewal processes. That gives you multiple layers of assurance that you probably wanted to have anyways.
Finally, it seems like the importance of encrypting all Internet traffic is just missing from the calculus presented here; that's just silly. I'm not going to go into it. It isn't imperative that literally every website is always encrypted all of the time, but for a multitude of reasons it is ideal if 99% of them are 99% of the time. Let's Encrypt might allow for a MitM if you can pass HTTP-01 or DNS-01 momentarily, but you know what's even easier? Just being literally anywhere in the path of someone's HTTP connection and being able to perform a MitM with having compromised nothing about the CA system or the website itself. Even if we allow for some sites to sit back on HTTP, it matters that 99% of the Internet is on HTTPS because it makes MitM attacks like this highly unattractive. This is good when you're on untrusted or potentially adversarial networks... Which is increasingly many of them.
The other thing missing here is just how clever the CA system has gotten. Mozilla and Google have together made this system work surprisingly well despite its flaws. The CT system makes issuing bad certificates very unattractive, as Google and Mozilla can fiercely enforce the rules, and CT makes it nearly impossible to hide when you go against them. With CT, CAA records, and other tools available, you can at least know with damn near certainty if someone did exploit the CA system or your infrastructure and pull certificates for your properties. With these improvements, relying on the CA system doesn't feel nearly as ugly.
And also, you don't necessarily need to use LE. I think LE is the most competent of the ACME providers, but many paid services provide ACME support, and ZeroSSL provides another free ACME service.
Shorter lived certificates also have other benefits that are not mentioned. For example, if certificates can last 5 entire years, a revoked certificate also has to be able to last that long. This makes CRLs pretty much untenable, and forces something like OCSP, which is bad for privacy. Shorter certificate lifespans were a big part of how Firefox was able to leave OCSP behind in favor of a more advanced version of the CRL scheme, a solid win for both privacy and TLS latency.
All in all, the juice is clearly worth the squeeze.