You want to replace a procedure that not only supports but highly encourages (basically forces) automation of a repetitive task with a process that is needlessly manual and costs money?
I mean you can still go and pay for a cert, Let's Encrypt is far from the only CA.
But really, what is the madness here? Who cares if it goes down to 64 days, or less for that matter? My ACME clients certainly don't. Maybe anybody ingesting CT logs will notice the somewhat higher bandwidth requirements?
Make sure your ACME client supports ARI so that it automatically adjusts its renewal schedule and gracefully handles revocation and early reissue. Even 45 day certs will be renewed weeks in advance so a CA outage should not be a big deal.
I think the specific choice of 64 days is quite clever. Most ACME clients out there that don't yet use ARI are set up to renew after 60 days, which means anybody still running these will now still not run into expiry but will get a bunch of "your certs are about to expire" warnings from Let's Encrypt and also potentially their own monitoring, so they can update their automation accordingly. I think this choice demonstrates quite a bit of forethought and care for their users, kudos!
This is honestly very frustrating because we have a process that relies on getting a cert from another company that we have no control over and we cannot automate it. Hell we can't even get them to provide the cert correctly on the first attempt before we convert it to the format we need. This is going to just get more and more frustrating.
Your comment made me ponder: that kind of relationship would be easier to deal with if there were such a thing as an ACME proxy that the other company could run (if the process idiocy were fixed), so you could talk to them like any other CA, and their proxy could get the cert from a real CA.
i can envision a flow where - assuming you can get them to send signed certificates as email attachments - you could "mechanical turk" it.
an automated system on your end sends them a certificate request (i.e. an email in plain english requesting that they issue you a new certificate from an actual CSR attached to this mail)
a human on their side issues the certificate and sends the signed certificate back to a special inbox (e.g. by hitting reply)
a cron job on your end regularly fetches mails from that inbox, tries to parse the cert and either sends an email back to the issuer requesting changes or, on success, triggers the certificate to get installed
we're using something like this with our mobile phone carrier's billing department at $work: for our level1 support staff, creating or cancelling a SIM contract happens on an internal web portal that tightly integrates with other related services (e.g. asset management), but on the prvoider's end, every POST request to our API gets translated into a MAIL FROM/RCPT TO :^)
That is the entire point of this shortening though. This will continue until eventually doing it manually becomes so difficult, time consuming, and inconvenient that suddenly it magically becomes possible.
I really ought to take the time to write up a simple program that pokes ACME and my DNS server to make a new certificate, then learn enough systemd to make it run weekly.
singpolyma | 19 hours ago
Ugh. When will the madness end! Makes me almost wish for the days of paying for a cert...
[OP] fanf | 19 hours ago
February 2028 when lifetimes are reduced to 45 days: https://lobste.rs/s/r2bamx/decreasing_certificate_lifetimes_45
stephenr | 11 hours ago
You want to replace a procedure that not only supports but highly encourages (basically forces) automation of a repetitive task with a process that is needlessly manual and costs money?
arcade | 8 hours ago
I'm like 99.99% sure that was a joke.
stephenr | 8 hours ago
Poe's law is real my friend.
singpolyma | 5 hours ago
Hence almost
muvlon | 12 hours ago
I mean you can still go and pay for a cert, Let's Encrypt is far from the only CA.
But really, what is the madness here? Who cares if it goes down to 64 days, or less for that matter? My ACME clients certainly don't. Maybe anybody ingesting CT logs will notice the somewhat higher bandwidth requirements?
ptman | 11 hours ago
It's not a Let's Encrypt limit https://cabforum.org/working-groups/server/baseline-requirements/requirements/#632-certificate-operational-periods-and-key-pair-usage-periods
singpolyma | 5 hours ago
My acme clients will if anything goes wrong
[OP] fanf | 4 hours ago
Make sure your ACME client supports ARI so that it automatically adjusts its renewal schedule and gracefully handles revocation and early reissue. Even 45 day certs will be renewed weeks in advance so a CA outage should not be a big deal.
muvlon | 11 hours ago
I think the specific choice of 64 days is quite clever. Most ACME clients out there that don't yet use ARI are set up to renew after 60 days, which means anybody still running these will now still not run into expiry but will get a bunch of "your certs are about to expire" warnings from Let's Encrypt and also potentially their own monitoring, so they can update their automation accordingly. I think this choice demonstrates quite a bit of forethought and care for their users, kudos!
oliverpool | 11 hours ago
Nitpick : LE stopped sending such notices https://letsencrypt.org/2025/01/22/ending-expiration-emails
zod000 | 8 hours ago
This is honestly very frustrating because we have a process that relies on getting a cert from another company that we have no control over and we cannot automate it. Hell we can't even get them to provide the cert correctly on the first attempt before we convert it to the format we need. This is going to just get more and more frustrating.
[OP] fanf | 5 hours ago
Yeah that kind of idiocy is annoying.
Your comment made me ponder: that kind of relationship would be easier to deal with if there were such a thing as an ACME proxy that the other company could run (if the process idiocy were fixed), so you could talk to them like any other CA, and their proxy could get the cert from a real CA.
Turns out, https://acme-proxy.github.io/acme-proxy/introduction.html
gir | 4 hours ago
i can envision a flow where - assuming you can get them to send signed certificates as email attachments - you could "mechanical turk" it.
we're using something like this with our mobile phone carrier's billing department at $work: for our level1 support staff, creating or cancelling a SIM contract happens on an internal web portal that tightly integrates with other related services (e.g. asset management), but on the prvoider's end, every POST request to our API gets translated into a MAIL FROM/RCPT TO :^)
Pandora | an hour ago
That is the entire point of this shortening though. This will continue until eventually doing it manually becomes so difficult, time consuming, and inconvenient that suddenly it magically becomes possible.
JulianSildenLanglo | 13 hours ago
I really ought to take the time to write up a simple program that pokes ACME and my DNS server to make a new certificate, then learn enough systemd to make it run weekly.
hailey | 11 hours ago
Check out https://github.com/dehydrated-io/dehydrated - its a shell script you can just drop on a server and go