4 ms·

I think the author has missed the point of the 47 day expiry. It is short enough to force teams to automate the process. You're not supposed to be human-actio

I think the author has missed the point of the 47 day expiry. It is short enough to force teams to automate the process. You're not supposed to be human-actioning something every month. But yes, it'll be a huge headache for teams that stick their head in the sand and think, "We don't need to automate this, it's just 6 months". As the window decreases to 3 months it'll be even more frustrating, and then will come a breaking point when it finally rests at 47 days. But the schedule is well advertised. The time to get automation into your certificate renewal is now. In the real world however, this will be a LOT of teams. I think the organisations defining this has missed just how much legacy and manual processes are out there, and the impact that this has on them. I don't think this post makes that argument well enough, instead trying to argue the technical aspect of ACME not being good enough. ACME is irrelevant in the face of organisations not even trying, and wondering why they have a pain every 6 weeks.

rini17 1y ago
When it's automated we're back at square one: after few years it breaks and nobody will have any idea where the acme scripts are or how to debug them.
- sam_lowry_ 1y ago
  I already had this with the certbot on Debian that was running perfectly for 5-6 years by that time.
- pferde 1y ago
  That could be an argument against automating anything, ever. The solution is just like with any other automation - document it.
  - quesera 1y ago
    ... which is also the solution for any other infrequent manual process. :)
- syncsynchalt 1y ago
  And if something silently breaks, would you rather the breakage is noticed within 47 days, or 398 days? Even your unrelated question is another argument for shortened certificate lifetimes. :-)
  - rini17 1y ago
    Except that's not how this works. When a cron job fails, does not depend on how often it is ran.
ameliaquining 1y ago
Is there a different implementation timeline that you think would adequately address the legitimate concerns of orgs relying on legacy and manual processes? My model is that beyond a baseline of a couple years (which were already granted), adding more time doesn't help, because these orgs will always procrastinate until the last minute on anything that doesn't seem to management like an obvious immediate priority. I think the CA/B Forum does understand this and that they're significantly inconveniencing a lot of people, but it has to happen sometime, and part of the purpose of the push for automation is to ensure that the inevitable future tightenings of security requirements won't require most orgs to do anything.
- xnorswap 1y ago
  Just extending the timeline won't help, as you suggest, if anything it'll make the problem even worse, by further bedding in the helpless. What typically does work for this kind of thing, is finding a hook to artificially rather than technically necessitate it, while not breaking legacy. For example, while I hate the monopoly that Google has on search, it was incredibly effective when they down-ranked HTTP sites in favour of HTTPs sites. ( In 2014: See https://developers.google.com/search/blog/2014/08/https-as-ranking-signal https://developers.google.com/search/blog/2014/08/https-as-r... ) Almost overnight, organisations that never gave a shit, suddenly found themselves rushing through the any required tech debt to get SSL certs and HTTPs in place. It was only after that drove up HTTPs to a critical mass did Google have the confidence to further nudge through bigger warnings in Chrome. ( 2018 ). Perhaps ChatGPT and has impacted Google's monopoly too much to try again, but they could easily rank results based on certificate validity length and try the same trick again.
  - ameliaquining 1y ago
    I can't see them doing that, because whether a site is using HTTPS is visible to end users, and Google and many others had already spent a lot of time and effort getting them to notice and care. By contrast, end users know nothing about certificate lifetimes, so it would be hard to explain this change to them.

rini17 1y ago

When it's automated we're back at square one: after few years it breaks and nobody will have any idea where the acme scripts are or how to debug them.

sam_lowry_ 1y ago
I already had this with the certbot on Debian that was running perfectly for 5-6 years by that time.
pferde 1y ago
That could be an argument against automating anything, ever. The solution is just like with any other automation - document it.
- quesera 1y ago
  ... which is also the solution for any other infrequent manual process. :)
syncsynchalt 1y ago
And if something silently breaks, would you rather the breakage is noticed within 47 days, or 398 days? Even your unrelated question is another argument for shortened certificate lifetimes. :-)
- rini17 1y ago
  Except that's not how this works. When a cron job fails, does not depend on how often it is ran.

ameliaquining 1y ago

Is there a different implementation timeline that you think would adequately address the legitimate concerns of orgs relying on legacy and manual processes? My model is that beyond a baseline of a couple years (which were already granted), adding more time doesn't help, because these orgs will always procrastinate until the last minute on anything that doesn't seem to management like an obvious immediate priority. I think the CA/B Forum does understand this and that they're significantly inconveniencing a lot of people, but it has to happen sometime, and part of the purpose of the push for automation is to ensure that the inevitable future tightenings of security requirements won't require most orgs to do anything.

xnorswap 1y ago
Just extending the timeline won't help, as you suggest, if anything it'll make the problem even worse, by further bedding in the helpless. What typically does work for this kind of thing, is finding a hook to artificially rather than technically necessitate it, while not breaking legacy. For example, while I hate the monopoly that Google has on search, it was incredibly effective when they down-ranked HTTP sites in favour of HTTPs sites. ( In 2014: See https://developers.google.com/search/blog/2014/08/https-as-ranking-signal https://developers.google.com/search/blog/2014/08/https-as-r... ) Almost overnight, organisations that never gave a shit, suddenly found themselves rushing through the any required tech debt to get SSL certs and HTTPs in place. It was only after that drove up HTTPs to a critical mass did Google have the confidence to further nudge through bigger warnings in Chrome. ( 2018 ). Perhaps ChatGPT and has impacted Google's monopoly too much to try again, but they could easily rank results based on certificate validity length and try the same trick again.
- ameliaquining 1y ago
  I can't see them doing that, because whether a site is using HTTPS is visible to end users, and Google and many others had already spent a lot of time and effort getting them to notice and care. By contrast, end users know nothing about certificate lifetimes, so it would be hard to explain this change to them.