Live data from Hacker News

Decreasing Certificate Lifetimes to 45 Days

letsencrypt.org

31–40 of 158 posts

Re: Decreasing Certificate Lifetimes to 45 Days

#31
I understand all of the benefits with regards to compromise and pushing automation, but I really hope they don't push the maximum lower.

It is already getting dangerously close to the duration of holiday freeze windows, compliance/audit enforced windows, etc.

Not to mention the undue bloat of CT logs.

Re: Decreasing Certificate Lifetimes to 45 Days

#32

As someone who works at a company who has to manage millions of SSL certificates for IoT devices in extremely terrible network situations I dread this. One of the biggest issues is handling renewals at scale, and I hate it. Another increasingly frusturation is challenges via DNS are not quick.

Are these IoT devices expected to be accessible via a regular Web browser from the public Internet? Does each of them represent a separate domain than needs a separate certificate, which it must not share with other similar devices?

Re: Decreasing Certificate Lifetimes to 45 Days

#33
post #29

Since we're on the topic of certificates, my app (1M+ logins per day) uses certificate pinning with a cert that lasts for one year, because otherwise it would be a nightmare to roll the cert multiple times in production. But what would be the "modern" way to do smart and automated certificate pinning, now that short-lived certs are becoming the trend?

Pin the cert authority instead?

This, and lock the account ID via CAA record.

Re: Decreasing Certificate Lifetimes to 45 Days

#35

Since we're on the topic of certificates, my app (1M+ logins per day) uses certificate pinning with a cert that lasts for one year, because otherwise it would be a nightmare to roll the cert multiple times in production. But what would be the "modern" way to do smart and automated certificate pinning, now that short-lived certs are becoming the trend?

The certificates will expire, but (as far as I'm aware), you're still allowed to use the same private key for multiple certificates, so as long as you pin to the public key instead of to the certificate itself, you should be fine.

The real modern way to do certificate pinning is to not do certificate pinning at all, but I'm sure that you've already heard this countless times before. An alternative option would be to run your own private CA, generate a new public/private keypair every 45 days, and generate certificates with that public key using both your private CA and Let's Encrypt, and then pin your private CA instead of the leaf certificates.

Re: Decreasing Certificate Lifetimes to 45 Days

#36

Since we're on the topic of certificates, my app (1M+ logins per day) uses certificate pinning with a cert that lasts for one year, because otherwise it would be a nightmare to roll the cert multiple times in production. But what would be the "modern" way to do smart and automated certificate pinning, now that short-lived certs are becoming the trend?

Pin the public key (SPKI) or CA.

Re: Decreasing Certificate Lifetimes to 45 Days

#38
Cert lifetimes are such a burden. I wanted to provide pre-configured server examples of my WebRTC project, something that was download-and-run without any more prior knowledge (an important point), which users could access from their LAN e.g. to test the examples from their phones (not from the useless localhost exemption that exists for secure contexts), for which a self-signed cert embedded in the examples was fine. New users could run them, new concepts (such as security and certificate management in production apps) could be learned at an apropriate time.

Until web browsers started to believe that no, that was too much of a convenience, so now long expiration certs became rejected. What's the proposed solution from the "industry"? to run a whole automation pipeline just to update a file in each example folder every few months? bonkers. These should be static examples, no reason to having to update those any earlier than every few years, at most.

Re: Decreasing Certificate Lifetimes to 45 Days

#40

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")…

> 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…

> 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?

Post reply on HN