I'm all for it -- it's hard to understate the extent to which LetsEncrypt has improved the WebPKI situation. Although the effective single-vendor situation isn't great, the "this is just something you only do via an automated API" approach is absolutely the right one. And certificate lifetimes measured in days work just fine with that.

The only things that continue to amaze me are the number of (mostly "enterprise") software products that simply won't get with the times (or get it wrong, like renewing the cert, but continuing to use the old one until something is manually restarted), and the countless IT departments that still don't support any kind of API for their internal domains...

▲

crote 39 minutes ago | parent | next [-]

It's not single-vendor. The ACME protocol is also supported by the likes of GlobalSign, Sectigo, and Digicert.

You've got to remember that the reduction to a 45-day duration is industry-wide - driven by the browsers. Any CA not offering automated renewal (which in practice means ACME) is going to lose a lot of customers over the next few years.

▲

ZeroConcerns 31 minutes ago | parent [-]

Effectively single-vendor. I'm not aware of any ACME-compatible CAs that don't have pernicious limits on their free plans (and if there are, I'd love to hear!), and here in the EU we've even recently lost a rather big player...

	▲	dmurray 8 minutes ago \| parent \| next [-]
		"multiple vendors, but only one of them is nice enough to give the product away for free" is not "effectively single-vendor". The other CAs aren't prohibitively priced for anyone who has a business need for lots of certificates, in case Let's Encrypt disappears or goes rogue.
	▲	arp242 3 minutes ago \| parent \| prev [-]
		Doesn't ZeroSSL do this? acme.sh has been using it as the default for the last few years. As I understand it, it basically offers the same as Let's Encrypt.

▲

schmuckonwheels an hour ago | parent | prev [-]

> The only things that continue to amaze me are the number of (mostly "enterprise") software products that simply won't get with the times

Yeah, no one's rewriting a bunch of software to support automating a specific, internet-facing, sometimes-reliable CA.

Yes it's ACME, a standard you say. A standard protocol with nonstop changing profile requirements at LE's whim. Who's going to keep updating the software every 3 months to keep up? When the WebPKI sneeze in a different direction and change their minds yet again. Because 45 will become 30 will become 7 and they won't stop till the lifetime is 6 hours.

"Enterprise" products are more often than not using internal PKI so it's a waste.

I would like to see the metrics on how much time and resources are wasted babysitting all this automation vs. going in and updating a certificate manually once a year and not having to worry the automation will fail in a week.

	▲	crote 5 minutes ago \| parent \| next [-]
		The change in validity does not in any way alter the protocol itself. As mentioned in the linked blog post: if you've already got automated cert renewal, it'll almost certainly require zero change. After all, the logical approach is to schedule a daily cron job for your renewal process, which only contacts the server when the current cert has less than X days of validity remaining. Scheduling a one-off cron job every, say, 60 days would be extremely error-prone! With regards to future reductions: the point is to force companies to automate renewal, as they have proven to be unable to renew in time during incidents due to dozens of layers of bureaucracy. 45 days means one renewal a month, which is probably sufficient for that. Anything below 7 days isn't likely to happen, because at that point the industry considers certification revocation unnecessary. Internal PKI is not relevant here. Anyone with weird internal cert use shouldn't be using public certs anyways, so moving those people to certs backed by self-signed internal CAs is a win. They are free to use whatever validity they want with those.
	▲	happymellon 8 minutes ago \| parent \| prev \| next [-]
		> I would like to see the metrics on how much time and resources are wasted babysitting all this automation vs. going in and updating a certificate manually once a year and not having to worry the automation will fail in a week. I have multiple systems. Legacy that I've inherited, and modern that are able to automatically update their certs. The automated updates require almost zero maintenance, there was a week a couple of years ago when I had to switch some configuration for a new root cert. The legacy system requires manual installation and multiple weeks of my time every year because of the number of environments, and since generation of the certs requires me to file a request for someone to manually create it, they invariably typo something and it has to be redone everywhere. So multiple engineers, over multiple weeks? Manual process at a guess is £50k pa, while the automated is close to an annual £0?
	▲	ZeroConcerns 25 minutes ago \| parent \| prev [-]
		> I would like to see the metrics Well, I could regale you with my anecdotes on how all my 'grab a LetsEncrypt cert on Docker deploy and whenever remaining lifetime goes below 75%' services have not had a single TLS-related outage in at least a year, and how we just had a multi-day meltdown caused by a load-bearing cert that everyone forgot about expiring, but I doubt you'll be interested. I'm not here to take away your right to set up a few more 5-year+ internal CAs (or, hey, how about an entire self-signed hierarchy? can't be that hard...), and neither is LetsEncrypt. But on the Big Bad Internet (where Google is the leading cause of More Security, and LetsEncrypt is merely the leading vendor catering to that), things have moved on slightly.