Earlier quoted context omitted.
7 days is too long! It should be 30 minutes!
Certificate per request
Of course, so we have another global failure/censorship point besides Cloudflare…
Decreasing Certificate Lifetimes to 45 Days
61–70 of 158 posts
Re: Decreasing Certificate Lifetimes to 45 Days
#62Re: Decreasing Certificate Lifetimes to 45 Days
#63One way to protest against this would be to run our cert revoke&update script every hour.
Re: Decreasing Certificate Lifetimes to 45 Days
#64The relevant section of the CA/Browser forum requirements that resulted in this change are here: https://cabforum.org/working-groups/server/baseline-requirem...
That's the decision. Do you know the reasoning?
Re: Decreasing Certificate Lifetimes to 45 Days
#65Earlier quoted context omitted.
> 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…
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 requires manual intervention. It's ridiculous.
Re: Decreasing Certificate Lifetimes to 45 Days
#66"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 type in that list is TLS-ALPN-01 which they dissuade you from! "This challenge is not suitable for most people."
And yet when you look at the ACME Client for JVM frameworks like Micronaut [1], the default is TLS and its the simplest to set up (no DNS access or external webserver). Crazy.
[0] https://letsencrypt.org/docs/challenge-types/
[1] https://micronaut-projects.github.io/micronaut-acme/5.5.0/gu...
Re: Decreasing Certificate Lifetimes to 45 Days
#67Earlier quoted context omitted.
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.
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...
Google Trust Services: https://pki.goog/
Re: Decreasing Certificate Lifetimes to 45 Days
#68Earlier 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…
at this point PEM is more standard and prevalent than pkcs#12
Re: Decreasing Certificate Lifetimes to 45 Days
#69[dead]
Re: Decreasing Certificate Lifetimes to 45 Days
#70> 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.
a perhaps non-obvious option is to CNAME (or NS) the `_acme_challenge` record from your main zone to another zone you can control better and can't affect production traffic the same way the main zone could. `acme-dns` is a neat little tool for exactly this, that has an https api for your ACME client to request a cert from, and a dns server to respond to dns-01 challenges from your provider.