> Decreasing Certificate Lifetimes to 45 Days
45 days ? So long ? Who needs so long living certificates ? A couple of miliseconds shall be enough. /s
Decreasing Certificate Lifetimes to 45 Days
41–50 of 158 posts
Re: Decreasing Certificate Lifetimes to 45 Days
#42Earlier 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...
"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.
Re: Decreasing Certificate Lifetimes to 45 Days
#43Earlier quoted context omitted.
What kind of issues do you usually face?
Without getting into specific stuff I've run into, automated stuff just, breaks. This is a living organism with moving parts and a time limit - you update nginx with a change that breaks .well-known by accident, or upgrade to a new version of Ubuntu and suddenly some dependency isn't loading correctly, or that UUID generator you depended on to generate the name for the challenge doesn't get loaded, or certbot becomes…
AKA the real world, a place where you have older appliances, legacy servers, contractual constraints and better things to do than watch a nasty yearly ritual become a nasty monthly ritual.
I need to make sure SSL is working in a bunch of very heterogeneous stuff but not in a position to replace it and/or pick an authority with better automation. I just suck it up and dread when a "cert day" looms closer.
Sometimes these kind of decisions seem to come from bodies that think the Internet exists solely for doing the thing they do.
Happens to me with the QA people at our org. They behave as if anything happens just for the purpose of having them measure it, creating a Heisenberg situation where their incessant narrow-minded meddling makes actually doing anything nearly imposible.
Re: Decreasing Certificate Lifetimes to 45 Days
#44Cert 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…
Wouldn't it be better to bundle a script that generates a cert instead of the cert itself?
Re: Decreasing Certificate Lifetimes to 45 Days
#45I'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…
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.
Re: Decreasing Certificate Lifetimes to 45 Days
#46Why not 7 days then
According to TFA LE already offers a "shortlived" profile that issues 6-day certs if you want to stress test your automation, or just gain the security advantages of rapid certificate turnover immediately.
The goal is to move to short lived certs to make the fragile system of revocation lists and public certificate logs unnecessary.
Re: Decreasing Certificate Lifetimes to 45 Days
#47Earlier 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...
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.
Re: Decreasing Certificate Lifetimes to 45 Days
#48I’m maintaining a server with Let’s Encrypt certs for a B2B integration platform. Some partner systems still can’t just pin the CA and instead require a manual certificate update on their side. So every 90 days we do the same email ping-pong to get them to install the new cert — and now that window is getting cut in half.
Hopefully their software stack will be able to automate this by 2028.
Re: Decreasing Certificate Lifetimes to 45 Days
#49Earlier quoted context omitted.
What kind of issues do you usually face?
Without getting into specific stuff I've run into, automated stuff just, breaks. This is a living organism with moving parts and a time limit - you update nginx with a change that breaks .well-known by accident, or upgrade to a new version of Ubuntu and suddenly some dependency isn't loading correctly, or that UUID generator you depended on to generate the name for the challenge doesn't get loaded, or certbot becomes…
The same happens with manual processes done once a year - you just aren't aware of it until renewal.
Consider the inevitable need for immediate renewal due to an incident. Would you rather have this renewal happen via a fast, automated and well-tested process, or a silently broken slow and manual one?
Re: Decreasing Certificate Lifetimes to 45 Days
#50Translation: Like any large bureaucracy, the certificate industry sees its own growth as a moral virtue, and no limits to the burdens which it should be free to impose on the rest of society.