Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Decreasing Certificate Lifetimes to 45 Days

letsencrypt.org

Post reply on HN
Print view View original

81–90 of 158 posts

Re: Decreasing Certificate Lifetimes to 45 Days

#81

Post by chrismorgan »

imtringued wrote: post #66
jakeogh wrote: post #3

"This change is being made along with the rest of the industry, as required by the CA/Browser Forum Baseline Requirements, which set the technical requirements that we must follow." I dont follow. Why? Why not an hour? A ssl failure is a very effective way to shut down a site. "you should verify that your automation is compatible with certificates that have shorter validity periods. To ensure your ACME client renews…

>Oh that sounds wonderful. So every small site that took the LE bait needs expensive help to stay online. I agree with the terminology "bait", because the defaults advocated by letsencrypt are horrible. Look at this guide [0]. They strongly push you towards the HTTP-01 challenge which is the one that requires the most amount of infrastructure (http webserver + certbot) and is the hardest to setup. The best challenge…

> the defaults advocated by letsencrypt are horrible

You’re completely misinterpreting the linked document. See what it says at the start:

> Most of the time, this validation is handled automatically by your ACME client, but if you need to make some more complex configuration decisions, it’s useful to know more about them. If you’re unsure, go with your client’s defaults or with HTTP-01.

This is absolutely the correct advice. For Micronaut, this will guide you to using TLS-ALPN-01, which is better than HTTP-01 if the software supports it. But for a user who doesn’t know what’s what, HTTP-01 is both the easiest and the most reliable, because, as they say, “It works with off-the-shelf web servers.” Typical web servers which don’t know about ACME themselves can be told “serve the contents of such-and-such a directory at /.well-known/acme-challenge/” which is enough to facilitate HTTP-01 through another client; but they don’t give you the TLS handshake control required to facilitate TLS-ALPN-01.

Re: Decreasing Certificate Lifetimes to 45 Days

#82

Post by inejge »

redrove wrote: post #16
secret-noun wrote: post #4

> The key advantage of [DNS-PERSIST-01] is that the DNS TXT entry used to demonstrate control does not have to change every renewal. > We expect DNS-PERSIST-01 to be available in 2026 Very exciting! https://datatracker.ietf.org/doc/html/draft-sheurich-acme-dn...

Big news for both the lazy homelab admin that can set a TXT once and ultimately be more secure without spraying DNS Zone Edit tokens all over their infra AND for the poor enterprise folks that have to open a ticket and wait 3 weeks for a DNS record.

It will help that side of the process (although, as a sibling has noted, you can CNAME your way into a better-controlled update service), but the challenge of automating cert changes for various non-HTTP services, including various virtual or physical boxes with funky admin interfaces, remains. I don't expect that vendors will do much about that, and it will end up on admins' plates, as usual. There will be much grumbling, but fewer solutions.

Re: Decreasing Certificate Lifetimes to 45 Days

#83

Post by cpach »

inejge wrote: post #82
redrove wrote: post #16

Earlier quoted context omitted.

Big news for both the lazy homelab admin that can set a TXT once and ultimately be more secure without spraying DNS Zone Edit tokens all over their infra AND for the poor enterprise folks that have to open a ticket and wait 3 weeks for a DNS record.

It will help that side of the process (although, as a sibling has noted, you can CNAME your way into a better-controlled update service), but the challenge of automating cert changes for various non-HTTP services, including various virtual or physical boxes with funky admin interfaces, remains. I don't expect that vendors will do much about that, and it will end up on admins' plates, as usual. There will be much grum…

There are quite many solutions. For very funky systems, you can use a cert tied to a private CA. Then you can control the cert lifetimes. Or place them behind a reverse proxy that is easier to control.

Re: Decreasing Certificate Lifetimes to 45 Days

#84

Post by kevincox »

> Acceptable behavior includes renewing certificates at approximately two thirds of the way through the current certificate’s lifetime.

So you can start renewing with 30d of lifetime remaining. You probably want to retry once or twice before alerting. So lets say 28d between alert and expiry.

That seems somewhat reasonable. But is basically the lower margin of what I consider so. I feel like I should be able to walk away from a system for a month with no urgent maintenance needed. 28d is really cutting it close. I think the previous 60d was generous but that is probably a good thing.

I really hope they don't try to make it shorter than this. Because I really don't want to worry about certificate expiry during a vacation.

Alternatively they could make the acceptable behaviour much higher. For example make 32d certificates but it is acceptable to start renewing them after 24h. Because I don't really care how often my automation renews them. What matters is the time frame between being alerted due to renewal failure and expiry.

Re: Decreasing Certificate Lifetimes to 45 Days

#85

Post by cpach »

kevincox wrote: post #84

> Acceptable behavior includes renewing certificates at approximately two thirds of the way through the current certificate’s lifetime. So you can start renewing with 30d of lifetime remaining. You probably want to retry once or twice before alerting. So lets say 28d between alert and expiry. That seems somewhat reasonable. But is basically the lower margin of what I consider so. I feel like I should be able to walk…

“I really hope they don’t try to make it shorter than this. Because I really don’t want to worry about certificate expiry during a vacation.”

You might want to consider force-renewing all your certs a few days before your vacation. Then you can go away for over 40 days. (Unless something else breaks…)

Re: Decreasing Certificate Lifetimes to 45 Days

#86

Post by kevincox »

cpach wrote: post #85
kevincox wrote: post #84

> Acceptable behavior includes renewing certificates at approximately two thirds of the way through the current certificate’s lifetime. So you can start renewing with 30d of lifetime remaining. You probably want to retry once or twice before alerting. So lets say 28d between alert and expiry. That seems somewhat reasonable. But is basically the lower margin of what I consider so. I feel like I should be able to walk…

“I really hope they don’t try to make it shorter than this. Because I really don’t want to worry about certificate expiry during a vacation.” You might want to consider force-renewing all your certs a few days before your vacation. Then you can go away for over 40 days. (Unless something else breaks…)

Might not be a bad idea if it is within their rate limit rules but I'd really rather not take a manual action before leaving a system alone for a while and not worry that I managed to force renew every single cert.

Re: Decreasing Certificate Lifetimes to 45 Days

#87

Post by cpach »

kevincox wrote: post #86
cpach wrote: post #85

Earlier quoted context omitted.

“I really hope they don’t try to make it shorter than this. Because I really don’t want to worry about certificate expiry during a vacation.” You might want to consider force-renewing all your certs a few days before your vacation. Then you can go away for over 40 days. (Unless something else breaks…)

Might not be a bad idea if it is within their rate limit rules but I'd really rather not take a manual action before leaving a system alone for a while and not worry that I managed to force renew every single cert.

If you forget a cert then you’re no worse off than the case where the automation fails during the vacation.

You could also run a simple program that checks each site and tells you the remaining lifetime of the cert used, to verify that you didn’t miss any cert.

It all depends on the scale of your operations, of course.

Re: Decreasing Certificate Lifetimes to 45 Days

#88

Post by cpach »

cpach wrote: post #77
ptman wrote: post #64

Earlier quoted context omitted.

That's the decision. Do you know the reasoning?

The primary reason: Revocation doesn’t work for webscale (OCSP is now obsolete). So instead, shorter cert lifetimes.

PS. Saw this insightful comment over on Lobsters:

“One quantitative benefit is that the maximum lifetime of certificates sets a bound on the size of certificate revocation lists. John Schanck has done heroic work on CRLite at Mozilla to compress CRLs, and the reduction from 398 days to 47 days further shrinks them by a factor of more than 8. For Let’s Encrypt the current limit is 90, so a more modest but still useful factor of 2.”

https://lobste.rs/s/r2bamx/decreasing_certificate_lifetimes_...

Re: Decreasing Certificate Lifetimes to 45 Days

#89

Post by jeroenhd »

raizer88 wrote: post #23

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?

Pinning the intermediate CA should work. Alternatively, calculate the cost of updating the cert pinning mechanism if it's custom and compare it to paid, 1 year certificates (though those will go away eventually too).

On the other hand, if you're using an app specific server, there's no need for you to use public certificates. A self-generated one with a five or ten year validity will pin just as nicely. That breaks if you need web browsers or third parties to talk to the same API, of course.

Re: Decreasing Certificate Lifetimes to 45 Days

#90

Post by SAI_Peregrinus »

imtringued wrote: post #65
homebrewer wrote: post #52

Earlier quoted context omitted.

In circles I'm running in, automatic certificate renewal has not caused a single problem over 7 years of using it, and whatever time was spent on setting it up, has paid many times over, both in saving effort on renewal, and in putting out fires when (not if ) someone forgets to renew a certificate. You just have to be careful picking your automation — I haven't been impressed with certbot, for example. Also, everyth…

Forcing automation would be fine if the default software package (certbot) was any good but from my experience certbot is simply not fit for purpose. Certbot doesn't support the industry standard PKCS#12 format, which makes it extremely brittle for anyone using a Java based webserver. Instead it uses the non-standard PEM format which requires conversion before usage. That conversion step breaks all the time and requi…

PEM is standardized in RFC 7468, from 2015 [1]. PEM has been an industry standard for a decade.

[1]https://datatracker.ietf.org/doc/html/rfc7468

Post reply on HN