Hacker News Reader

Comment by jfindper | Hacker News Reader

While I believe you're posting questions out of frustration rather than genuine curiosity, I think it's worth pointing out two things.

One: most of the reasoning is available for reading. Lots of discussion was had. If you're actually curious, I would suggest starting with the CA/B mailing group. Some conversation is in the MDSP (Mozilla's dev-security-policy) archives as well.

Two: it's good to remember that the competing interests in almost every security-related conversation is the balance between security and usability. Obviously, a 60-second lifetime is unusable. The goal is to get the overlap between secure and usable to be as big as possible.

View on HN

serious q: maybe not 60 sec, but why 45 days instead of ~1 day or even hours? at 45 days, it pretty much has to be automated.

They are not sadists, contrary to what others say in the comments.

Although for the benefit of masochists, they are going to offer 6 day certs as an option soon.

Yep, the "shortlived" (6-day) profile will be available to the general public later this week. But at this time we explicitly encourage only mature organizations with stable infrastructure and an oncall rotation to adopt that profile, as the risks associated with a renewal failing at the beginning of a holiday long weekend are just too high for many sites.

Our internal CAs run 72 hour TTLs, because we figured "why not" 5-6 years ago, and now everyone is too stubborn to stop. You'd be surprised how much software is bad at handling certificates well.

It ranges from old systems like libpq which just loads certs on connection creation to my knowledge, so it works, down to some JS or Java libraries that just read certs into main memory on startup and never deal with them again. Or other software folding a feature request like "reload certs on SIGHUP" with "oh, transparently do listen socket transfer between listener threads on SIGHUP", and the latter is hard and thus both never happen.

45 days is going to be a huge pain for legacy systems. Less than 2 weeks is a huge pain even with modern frameworks. Even Spring didn't do it right until a year or two ago and we had to keep in-house hacks around.

Honest reply: because the infrastructure isn't ready to support 1-day certificates yet. If your cert is only valid for one day, and renewal fails on a Saturday, then your site is unusable until you get back to work on Monday and do something to fix it. There are things that can be done to mitigate this risk, like using an ACME client which supports fallback between multiple CAs, but the vast majority of sites out there today simply aren't set up to handle that yet.

The point of the CA/BF settling on 47-day certs is yes, to strongly push automation, but also to still allow time for manual intervention when automation fails.

The 7-day certificate will be here before you know it [1].

[1]: https://letsencrypt.org/docs/profiles/#shortlived

asynchronous revocation check would be far superior option; I'm sad industry abandoned trying to make it work.

The article does link in multiple places to another article discussing why revocation checks do not work for privacy (you're telling someone your browsing history basically) and reliability (what if the CA's revocation checker goes down?) reasons.

Reply on news.ycombinator.com