If you want to update your ACME configuration to use these new 64-day certs now to get a head start on the transition... there's currently no way to do so.
LE for reasons unknown did not opt to use their "profile" capability to allow subscribers to select 64 day certs as an option. They mention that they will update their staging environment on 2026-10-14 to use 64 day lifetimes, presumably with the "classsic" profile although they do not specify. But the staging env is not useful if you need a valid browser-trusted cert.
I've worked with Let's Encrypt (I mean inside the organization, not just as an end user) a bunch and I feel like I often know or can guess rationales for things, but while I know "why short-lived certs", I surely don't know "why 64".
Because large organisations have demonstrated over time that they are fundamentally incapable of managing their certs effectively.
They usually grow enormous bureaucratic theatre around long-lived cert renewal, leaving them unable to do rapid rotation when it is required. And rather than getting their shit together, they prefer suing their CA to avoid revocation.
Given that those organisations 1) are crucial for day-to-day life (like banks, or the government), and 2) would have a giant blast radius when their certs are compromised, and 3) won't voluntarily change, the only remaining option to keep the ecosystem healthy is to force them by making complex rotation processes extremely painful and cumbersome to keep.
Hence: automated renewal, and boil the frog by slowly lowering the validity period.
Agreed, there is a problem with how certs are managed in large organizations.
Many believe a Wildcard cert is a license to copy the same private key and cert everywhere. They have no problem
copying their single private key to budget VPS services or foreign providers
who are known CLOUD and collection program participants, the same private key
used for "high security" on premise servers.
Also amusing to see some organizations using ACME cert tools manually on each
and every server in fleets of 10 to 100, every 80 days or so, when they remember to do so. Outages
tend to be pretty frequent due to missed renewals.
The only solution is automation, whether with an off the shelf ACME client with
a cron job or a more complete automation platform. Let's Encrypt is not the
only CA that supports automation, there are quite a few that support ACME or
other nonstandard APIs. There is almost no setup that cannot be fully
automated: legacy web servers, hardware load balancers, cloud load balancers,
etc.
It is also absolutely possible to automate OV and EV renovation if an
organization insists on these "fancy" certs, which are frankly irrelevant to
security because browsers do not treat them differently in any significant way.
You can't pin a domain to only OV or EV type certs, which would be useful. The
documents used for validation need to be updated periodically (data reuse
times are going down too), but the rest of the process can be fully automated.
I do not see any reason not to automate cert renewal given the changes in
lifetimes, although I feel for the hobby server operators who have to deal with
more complexity. For hobby use cases, just set up an ACME client with a cron
job and be done with it.
I thought it was to force people who are running smaller services to give up. Decreasing the number of services on the internet decreases its total attack surface, therefore simple logic dictates that to maximize total internet security we should make it as difficult and expensive as possible to operate a service on the internet.
I agree with you that it's a very good thing, although I think the automation is less the end goal and more a means to an end. The end in this case being moving the idea of webpki certs from pets to cattle and the positive impact that has on the security of webpki.
The original idea of these certs, that they're very valuable long-lived secrets that have to be carefully hand managed and protected, while simultaneously being accessible to your active infrastructure, was always going to be too brittle. The idea of short-lived secrets that are regularly reissued allows for much more robust validation and less catastrophic failure modes.
I'm generally not dogmatic about this kind of thing and think there are often multiple right answers. But short-lived webpki certs are one of those things where if people don't see the value, I'm convinced they're not thinking about security correctly.
Well, that is the nature of security theater. Busywork and process fragility with no or negative benefit.
In the past a long-lived EV certificate changing was notable/interesting from a security standpoint. Short-lived certificates just mean anyone who can break into your domain registrar (easy) can create an identical certificate and none of your key storage or security matters.
Even if your own personal key handling security measures are better than the security of your domain registrar, which I seriously doubt is the case for most people who handle certificates, the impact of an attacker managing to obtain your real long-lived cert is significantly worse.
An attacker who manages to get a cert provider to mint a new certificate for your domain might be able to appear legitimate, but remember that it's a new cert, not an identical one to the cert you already have. You as the domain owner can easily detect this new cert was created using CT logs and visitors to your site can potentially detect two certs for the same domain depending on whether the attacker can convince them to only visit the spoofed site. Short lived certificates also mean the attacker must execute their new cert attack frequently if they want longer term success.
On the other hand, an attacker who manages to penetrate your impenetrable personal cert management security measures now has the real cert they can use to pretend to be you for as long as your certificate is good for. And unless you detected their one-time break-in, there is no way for you or anyone else to tell this is happening since the attacker is using a cert that matches the real one byte for byte.
Edit: I forgot to mention that short-lived certs are also a response to the general challenge with certificate revocation mechanisms as a reliable way to respond to the unlikely event that you actually detected your long-lived cert was stolen. Even if you figured out an attacker stole your certificate, convincing users to not keep treating it as valid has a lot of interesting failure edge cases. You might just have to wait for its validity period to expire.
It's actually much worse than that. Institutions were rarely able to actually detect said compromise, leaving attackers with certs that were indistinguishable from the real thing and valid for a long period of time. Even when institutions could detect the compromise and could quickly rotate certs, getting users to not still trust the old ones could be a non-trivial challenge.
Because while the Internet and subsequently the WWW was conceived as a medium where all peers were treated equally and no centralized gatekeepers were required, this policy was widely viewed to be a Bad Idea in retrospect, treated as a bug, and fixed accordingly.
Here's the thing, you can write your own applications and security to do anything you want. There is no gun being pointed at you to stop you, at least on PC.
Now, if you want to play with the world at large that's been dealing with security issue after security issue then you play by those rules.
You can't come to my game then get mad when I have a set of rules you don't like.
Because the people on the CA/B Forum is doing security theater and doesn't have a practical view of security risks. But the tech companies that employ them view them as authorities and won't fire them for promoting dumb ideas.
The CA/B is the embodiment of the phrase "if all you have is a hammer, everything looks like a nail".
CAs aren't the ones pushing for the shorten cert lifetimes, it's the Browsers. ICYMI, the "tech companies" like Google and Apple are the ones pushing for this and they pretty much control the browsers at this point.
It's like the FIDO(?) Working Group and passkeys. "Don't you try to offer exporting or sharing passkeys between devices or we'll revoke your ability to be a trusted origin for relying parties", meanwhile "Oh, Apple wants to offer this via AirDrop? Step right up." Rules for the big boys, not for you.
If you want to update your ACME configuration to use these new 64-day certs now to get a head start on the transition... there's currently no way to do so.
LE for reasons unknown did not opt to use their "profile" capability to allow subscribers to select 64 day certs as an option. They mention that they will update their staging environment on 2026-10-14 to use 64 day lifetimes, presumably with the "classsic" profile although they do not specify. But the staging env is not useful if you need a valid browser-trusted cert.
https://letsencrypt.org/docs/profiles/
You can however use the "tlsserver" profile to jump straight to 45 day certs.
https://letsencrypt.org/docs/profiles/#tlsserver
Confusing decision not to create a profile to help smooth the transition.
I've worked with Let's Encrypt (I mean inside the organization, not just as an end user) a bunch and I feel like I often know or can guess rationales for things, but while I know "why short-lived certs", I surely don't know "why 64".
Is it because it's a round number in binary?
64 days might seem like an arbitrary number, but it’s a simple cascade:
64 days = 2 maximal month (62 days) + 1 day wiggle room + 1 day because 63 would be even weirder.
I recently purchased an yearly wildcard SSL certificate and was notified that the certificate needs to be resigned every 200 days, why!?
Because large organisations have demonstrated over time that they are fundamentally incapable of managing their certs effectively.
They usually grow enormous bureaucratic theatre around long-lived cert renewal, leaving them unable to do rapid rotation when it is required. And rather than getting their shit together, they prefer suing their CA to avoid revocation.
Given that those organisations 1) are crucial for day-to-day life (like banks, or the government), and 2) would have a giant blast radius when their certs are compromised, and 3) won't voluntarily change, the only remaining option to keep the ecosystem healthy is to force them by making complex rotation processes extremely painful and cumbersome to keep.
Hence: automated renewal, and boil the frog by slowly lowering the validity period.
Agreed, there is a problem with how certs are managed in large organizations. Many believe a Wildcard cert is a license to copy the same private key and cert everywhere. They have no problem copying their single private key to budget VPS services or foreign providers who are known CLOUD and collection program participants, the same private key used for "high security" on premise servers.
Also amusing to see some organizations using ACME cert tools manually on each and every server in fleets of 10 to 100, every 80 days or so, when they remember to do so. Outages tend to be pretty frequent due to missed renewals.
The only solution is automation, whether with an off the shelf ACME client with a cron job or a more complete automation platform. Let's Encrypt is not the only CA that supports automation, there are quite a few that support ACME or other nonstandard APIs. There is almost no setup that cannot be fully automated: legacy web servers, hardware load balancers, cloud load balancers, etc.
It is also absolutely possible to automate OV and EV renovation if an organization insists on these "fancy" certs, which are frankly irrelevant to security because browsers do not treat them differently in any significant way. You can't pin a domain to only OV or EV type certs, which would be useful. The documents used for validation need to be updated periodically (data reuse times are going down too), but the rest of the process can be fully automated.
I do not see any reason not to automate cert renewal given the changes in lifetimes, although I feel for the hobby server operators who have to deal with more complexity. For hobby use cases, just set up an ACME client with a cron job and be done with it.
>There is almost no setup that cannot be fully automated
stares at that one IE6 interface in that one box in that particular network
i cant be the only one
To act as a forcing function to automate certificate issuance and rotation.
In aggregate this is a very good thing
I thought it was to force people who are running smaller services to give up. Decreasing the number of services on the internet decreases its total attack surface, therefore simple logic dictates that to maximize total internet security we should make it as difficult and expensive as possible to operate a service on the internet.
That’s total nonsense that makes absolutely no sense though?
It’s easier than ever to run “smaller services”. You don’t even need to pay for a TLS certificate.
I agree with you that it's a very good thing, although I think the automation is less the end goal and more a means to an end. The end in this case being moving the idea of webpki certs from pets to cattle and the positive impact that has on the security of webpki.
The original idea of these certs, that they're very valuable long-lived secrets that have to be carefully hand managed and protected, while simultaneously being accessible to your active infrastructure, was always going to be too brittle. The idea of short-lived secrets that are regularly reissued allows for much more robust validation and less catastrophic failure modes.
I'm generally not dogmatic about this kind of thing and think there are often multiple right answers. But short-lived webpki certs are one of those things where if people don't see the value, I'm convinced they're not thinking about security correctly.
It will merely mean any given legitimate certificate is indistinguishable from a newly minted malicious one.
As it is now then?
Well, that is the nature of security theater. Busywork and process fragility with no or negative benefit.
In the past a long-lived EV certificate changing was notable/interesting from a security standpoint. Short-lived certificates just mean anyone who can break into your domain registrar (easy) can create an identical certificate and none of your key storage or security matters.
Even if your own personal key handling security measures are better than the security of your domain registrar, which I seriously doubt is the case for most people who handle certificates, the impact of an attacker managing to obtain your real long-lived cert is significantly worse.
An attacker who manages to get a cert provider to mint a new certificate for your domain might be able to appear legitimate, but remember that it's a new cert, not an identical one to the cert you already have. You as the domain owner can easily detect this new cert was created using CT logs and visitors to your site can potentially detect two certs for the same domain depending on whether the attacker can convince them to only visit the spoofed site. Short lived certificates also mean the attacker must execute their new cert attack frequently if they want longer term success.
On the other hand, an attacker who manages to penetrate your impenetrable personal cert management security measures now has the real cert they can use to pretend to be you for as long as your certificate is good for. And unless you detected their one-time break-in, there is no way for you or anyone else to tell this is happening since the attacker is using a cert that matches the real one byte for byte.
Edit: I forgot to mention that short-lived certs are also a response to the general challenge with certificate revocation mechanisms as a reliable way to respond to the unlikely event that you actually detected your long-lived cert was stolen. Even if you figured out an attacker stole your certificate, convincing users to not keep treating it as valid has a lot of interesting failure edge cases. You might just have to wait for its validity period to expire.
The situation we found ourselves in is simple: institutions were systematically unable to quickly rotate certificates when they were compromised.
Precisely because of busywork and process fragility that they invented, with a strictly negative benefit for security and end-users.
Can you propose another path to address this issue?
It's actually much worse than that. Institutions were rarely able to actually detect said compromise, leaving attackers with certs that were indistinguishable from the real thing and valid for a long period of time. Even when institutions could detect the compromise and could quickly rotate certs, getting users to not still trust the old ones could be a non-trivial challenge.
Because while the Internet and subsequently the WWW was conceived as a medium where all peers were treated equally and no centralized gatekeepers were required, this policy was widely viewed to be a Bad Idea in retrospect, treated as a bug, and fixed accordingly.
Here's the thing, you can write your own applications and security to do anything you want. There is no gun being pointed at you to stop you, at least on PC.
Now, if you want to play with the world at large that's been dealing with security issue after security issue then you play by those rules.
You can't come to my game then get mad when I have a set of rules you don't like.
my game
Right, set up your own game table and you get to make the rules.
That or either get a democracy to agree with you and vote, or become a dictator.
Because the people on the CA/B Forum is doing security theater and doesn't have a practical view of security risks. But the tech companies that employ them view them as authorities and won't fire them for promoting dumb ideas.
The CA/B is the embodiment of the phrase "if all you have is a hammer, everything looks like a nail".
CAs aren't the ones pushing for the shorten cert lifetimes, it's the Browsers. ICYMI, the "tech companies" like Google and Apple are the ones pushing for this and they pretty much control the browsers at this point.
Indeed, and they control the CA/B Forum. The last CA to express an independent and reasonable view got booted from being a trusted CA.
It's like the FIDO(?) Working Group and passkeys. "Don't you try to offer exporting or sharing passkeys between devices or we'll revoke your ability to be a trusted origin for relying parties", meanwhile "Oh, Apple wants to offer this via AirDrop? Step right up." Rules for the big boys, not for you.
[flagged]
[dead]
At what point are we minting new certificates for each connection, and what does that mean for the original design?
You could also go straight for DANE and get rid of CAs entirely.
The safest certificates are the ones that have expired before they were generated. Zombie Cat Quantum Security Corporation FTW!
/s