Upcoming Changes to Let's Encrypt Certificates
Key topics
The internet is abuzz with concerns about Let's Encrypt's upcoming certificate changes, with some commenters warning that the short certificate lifetimes make it a central point of failure for much of the web. However, others point out that alternative free ACME-based providers exist, making it relatively painless to switch if needed, and suggest configuring backup certificate authorities to mitigate potential risks. The discussion reveals a nuanced debate, with some attributing the push for shorter certificates to the CA/Browser Forum, while others argue it benefits Let's Encrypt at the expense of commercial CAs. As the conversation unfolds, the need for a robust revocation mechanism becomes a pressing topic, with Mozilla's CRLite emerging as a potential solution.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
42m
Peak period
106
0-6h
Avg / period
16
Based on 160 loaded comments
Key moments
- 01Story posted
Dec 15, 2025 at 2:30 PM EST
25 days ago
Step 01 - 02First comment
Dec 15, 2025 at 3:12 PM EST
42m after posting
Step 02 - 03Peak activity
106 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 18, 2025 at 12:11 PM EST
22 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Google https://pki.goog/
SSL.com https://www.ssl.com/blogs/sslcom-supports-acme-protocol-ssl-...
ZeroSSL https://zerossl.com/documentation/acme/
I don't actually think Cloudflare runs an ACME Certificate Authority. They just partner with LetsEncrypt?
https://hacks.mozilla.org/2025/08/crlite-fast-private-and-co...
If everyone is too stupid to come up with a better system, that's okay! Go with the option that works in the real world.
That's been true for a while, regardless of cert length.
Everyone leans on them and unlike CF and other choke points of the internet...Let's Encrypt is a non-profit
yes
Absolutely. It feels like a matter of time before the current US administration will attempt to implement some authoritarian policy regarding certificates.
We're not quite there yet, but the logical progression of shorter and shorter certificate lifetimes to obviate the problems related to revocation lists would suggest that we eventually end up in a place where the major ACME CAs join the list of heavily-centralized companies which are dependencies of "the internet", alongside AWS, Cloudflare, and friends. With cert lifetimes measured in years or months, the CA can have a bad day and as long as you didn't wait until the last possible minute to renew, you're unimpacted. With cert lifetimes trending towards days or less, now your CA really does need institutionally important levels of high availability.
Hell, you can still set it to renew when cert still have month left.
I'm more worried that the clowns at the helm will push into something stupid like week or 3 days, "coz it improves security in some theoretical case"
I think that particular ship sailed a decade ago!
> Its less that LE becomes more of a single point of failure than it is that the concept of ACME CAs in general join the list of critically available things required to keep a site online.
Okay, this is what I wanted clarified. I don't disagree that CAs are critical infrastructure, and that there's latent risk whenever infrastructure becomes critical. I just think that risk is justified, and that LE in particular is no more or less of a SPOF with these policy changes.
Certificates have historically been a "fire and forget" but constantly re-issuance will make LE as important as DNS and web hosting.
The longer certificates were valid the more often we'd have breakage due to admins forgetting renewal, or how do install the new certificates. It was a daily occurrence, often with hours or days of downtime.
Today, it's so rare I don't even remember when I last encountered an expired certificate. And I'm pretty sure it's not because of better observability...
There are other CA with ACME support
Including paying CA, if you really want to pay : sectigo
You can renew your sectigo certificates with ACME so from a technical point of view, just trigger your cron more often
It's okay for something to be a good thing and to celebrate it. We don't have to frown about everything.
Oh and you would definitely know about this outage because you would hear about it in your news, and the monitoring you already have set up to yell at you when you cert is about to retire (you already have that right? Right?). And you can STILL trivially switch to another CA that supports ACME.
This isn't LE's decision: a 47 day max was voted on by the CA/Browser Forum.
https://www.digicert.com/blog/tls-certificate-lifetimes-will...
https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-sch...
https://groups.google.com/a/groups.cabforum.org/g/servercert... - public votes of all members, which were unanimously Yes or Abstain.
IMO this is a policy change that can Break the Internet, as many archived/legacy sites on old-school certificates may not be able to afford the upfront tech or ongoing labor to transition from annual to effectively-monthly renewals, and will simply be shut down.
And, per other comments, this will make LE the only viable option to modernize, and thus much more of a central point of failure than before.
But Let's Encrypt is not responsible for this move, and did not vote on the ballot.
LE isn't the only free ACME provider, just the best known. You can get your certs from ZeroSSL, Google or Actalis if you want.
Oh, on LE the Rate Limit Adjustment Request forms the contractual things (if that's what they are?) do not load: https://isrg.formstack.com/forms/rate_limit_adjustment_reque...
ZeroSSL, SSL.com and Actalis offer paid services on top of their basic free certificates.
Google is Google.
So your "free" ssl certs are provided by surveillance capitalism, and paid for with your privacy (and probably your website user's privacy too)?
I'm not sure that's technically true. As a CA they definitely have the power to facilitate a MitM attack. They can also issue fraudulent certificates.
> AIUI the ACME protocol never lets the CA see the private key, only the public key, which is public by definition anyway.
That has more to do with HTTPS end to end encryption, not the protocol of issuance.
They can do that anyway though, if any trusted CA goes rogue they can issue a fraudulent certificate for your site even if you've never intentionally requested a cert from them. That's just the nature of the game.
That's not really how ssl certs work - google isn't getting any information they wouldn't have otherwise had by issuing the ssl cert.
No, that's false. It's the other way around.
“If Caddy cannot get a certificate from Let's Encrypt, it will try with ZeroSSL”. Source: https://caddyserver.com/docs/automatic-https#issuer-fallback
Which makes sense, since the ACME access to ZeroSSL must go through an account created by a manual registration step. Unless the landscape changed very recently, LE is still the only free ACME that does not require registration. Source: https://poshac.me/docs/v4/Guides/ACME-CA-Comparison/#acme-ca...
https://github.com/caddyserver/caddy/releases/tag/v2.8.0
> Up to now, Caddy used both Let's Encrypt and ZeroSSL by default to get certificates without any configuration. In 2.8, this is changing slightly. Due to upcoming changes to ZeroSSL accounting policies, ZeroSSL now requires your email address to be able to access their free ACME endpoint.
> As such, Caddy will only implicitly add the ZeroSSL issuer to your config if you provide an email address in your Caddyfile using the email global option. (We have already recommended this for years.) If you already do this, you don't have to make any changes and you'll still get Let's Encrypt and ZeroSSL automatically as defaults.
Ideally, this will take less ongoing labor than annual manual rotations, and I'd argue sites that can't handle this would have been likely to break at the next annual rotation anyways.
If they have certificates managed by hosters, the hosters will deal with it. If they don't, then someone was already paying for the renewal and handling the replacement on the server side, making it much more likely that it will be fixed.
Nobody's paying for EV certificates now browsers don't display the EV details. The only reason to pay for a certificate is if you're rotating certificates manually, and the 90 day expiry of Lets Encrypt certificates is a hassle.
If the CA/Browser Forum is forcing everyone to run ACME clients (or outsource to a managed provider like AWS or Cloudflare) doesn't that eliminate the last substantial reason to give money to a CA?
Seems to me CAs have intermediate certificates and can rotate those, not much upside to rotating the root certificates, and lots of downsides.
1. These might need to happen as emergencies if something bad happens
2. If roots rotate often then we build the muscle of making sure trust bundles can be updated
I think the weird amount they are being rotated today is the real root cause if broken devices and we need to stop the bleed at some point.
Five years is not enough incentive to push this change. A TV manufacturer can simply shrug and claim that the device is not under warranty anymore. We'll only end up with more bricked devices.
Isn't this the whole point of intermediate certificates, though?
You know, all the CA's online systems only having an intermediate certificate (and even then, keeping it in a HSM) and the CA's root only being used for 20 seconds or so every year to update the intermediate certificates? And the rest of the time being locked up safer than Fort Knox?
Those are weaknesses. It’s also that a root rotation might be needed for completely stupid vulnerabilities. Like years later finding that specific key was generated incorrectly.
If the vendor is really unable to update, then it's at best negligence when designing the product, and at worst -- planned obsolescence.
2. Product is a smart fridge or whatever, reasonable users might keep it offline for 5+ years.
3. New homeowner connects it to the internet.
4. Security update fails because the security update server's SSL cert isn't signed by a trusted root.
We do car recalls all the time. Just send out an email or something with instructions of what to put on a USB, it's basically the same thing.
Yes it's inconvenient for consumers and annoying but the alternative is worse. Essentially hard coding certificates was always a bad idea.
Nothing stays the same forever, software is never done. It’s absurd pretend otherwise.
The CA folks and the Browser folks may have had differences of opinions.
Nearly all of the CAs present voted for it, and none against, with only a few abstains. I don't get their reasoning either, it seems like signing their own death warrant, but...
Microsoft voted for it, and now they are basically the only game in town for cloud signing that is affordable for individuals. The Forum needs voting representatives for software developers and end users or else the members will just keep enriching themselves at our expense.
They set the baseline standard for code signing certificates. In 2020 they added the requirement to use hardware modules which resulted in much higher prices and fewer small developers opting to sign their code.
I expect they will introduce new, "more secure", proprietary methods, and ride the vendor lock-in until the paid certificate industries death.
Large companies will keep on using paid providers also for business continuity in case free provider will fail. Also I don’t know what kind of SLA you have on let’s encrypt.
It is more complicated than „oh it is free let’s move on”.
> Next year, you’ll be able to opt-in to 45 day certificates for early adopters and testing via the tlsserver profile. In 2027, we’ll lower the default certificate lifetime to 64 days, and then to 45 in 2028.
If paid certs drop in max validity period, then yeah, zero reason to burn money for no reason.
One of my customers has an integration with the national customs authority, which requires a certificate granted specifically by the national certificate authority, which charges 500€ a year. Granted, the national CA also checks the customer's identity and company ownership, so it's not quite comparable to Let's Encrypt.
All of these required, complex, constantly moving components mean we're beholden to larger tech companies and can't do things by ourselves anymore without increasing effort. It also makes it easier for central government to start revoking access once they put a thumb on cert issuance. Parties that the powers don't like can be pruned through cert revocation. In the future issuance may be limited to parties with state IDs.
And because mainstream tech is now incompatible with any other distribution method, you suddenly lose the ability to broadcast ideas if you fall out of compliance. The levers of 1984.
PRISM works fine to recover HTTPS-protected communications. If anything NSA would be happier if every site they could use PRISM on used HTTPS, that's simply in keeping with NOBUS principles.
Source:
They collect it straight from the company after it's already been transmitted. It's not a wiretap, it's more akin to an automated subpoena enforcement.
To be honest, the "my blog doesn't need HTTPS" thing is kind of a privileged first-worlder luxury belief. You don't know how bad it is in other countries.
Of course I have modern laptops, but I still fire up my old Pismo PowerMac G3 occasionally to make sure my sites are still working on HTTP, accessible to old hardware, and rendering tolerably on old browsers.
The problem is not "your part", it's the "between you and the client" part.
It becomes trivial to inject extra content, malicious JavaScript, adverts etc into the flow. And this isn't "targetted" at your site, its simply applied to all insecure sites.
TLS is not about restricting your ability to broadcast information. It's about preserving your ability to guarentee that your reader reads what you wrote.
TLS is free and easy to implement. The only reason not to do it is laziness. You may see TLS as a violation of your principles- but I see it as an attitude of "I don't care about my readers safety - let someone inject malicious JavaScript (or worse) on my page, their security is not my problem".
(If the govt want to censor you they can do that via dns).
The analogous problem would be letters opened and anthrax inserted. That doesn't (often) happen because mail is physical and hard to do at scale. (And the anthrax cant mine bitcoin.)
Given the ineffectiveness of current laws around ransomware, bonnets, phishing, identity theft, online scams etc, I don't think a law saying "don't do that" would be a solution.
And ISPs are (by far) not the only offenders here. Every public wifi would be an equally attractive attack point.
But that is what ISPs did! Injecting (more) ads. Replaced ads with their own. Injecting Javascript for all sorts of things. Like loading a more compressed version of a JPEG and you had to click on a extra button to load the full thing. Removing the STARTTLS string from a SMTP connection. Early UMTS/G3 Vodafone was especially horrendous.
I also remember "art" projects where you could change the DNS of a public/school PC and it would change news stories on spiegel.de and the likes.
We're doing a beta of it for some other groups now. https://www.certkit.io/
Unfortunately, the people making these decisions simply do not care how they impact actual real world users. It happens over and over that browser makers dictate something that makes sense in a nice, pure theoretical context, but sucks ass for everyone stuck in the real world with all its complexities and shortcomings.
Google calls the shots and the others fall in line.
There are lots of organizations that support the ACME protocol. LE is the most well known, but there are others, and more on the way.
Existing CAs don't necessarily vanish with this change. They are free to implement ACME (or some proprietary protocol) and they are completely free to keep charging for certificates if they like.
The real result of this change is that processes will change (where they haven't already) improving both customer experience and security.
But to be clear there's no "one organization" in the loop here. You can rest easy on that front.
The vote was more about whether the CAB would continue to be relevant. "Accept the reality, or browsers aren't even going to show up anymore".
I wrote a bunch about this recently: https://www.certkit.io/blog/47-day-certificate-ultimatum
I do still feel that "that blog/publication that had immense cultural impact years ago, that was acquired/put on life support with annual certificate updates, will now be taken offline rather than migrated to a system that can support ACME automations, because the consultants charge more than the ad revenue" will be an unfortunate class of casualty. But that's progress, I suppose.
Today, people are complaining that automation of certificate renewals are annoying (I'm sure they were). Before that, the complaint was that random US companies were simply buying and deploying their own root certificates, issuing certs for arbitrary strangers domains, so their IT teams wouldn't have to update their desktop configurations.
Things are better now.
The difference being that there's at least a little bit of popular dissatisfaction with the status quo when it comes to browsers unilaterally dictating web standards, whereas nobody came to the defense of CAs, since everyone hated them. A useful lesson that you need to do reputation management even if you're running a successful racket, since if people hate you enough they might not stick up for you even if someone comes for you "illegally".
The CA industry is the new taxi industry.
The previous owners have valid certificates for up to 398 days. If they are a malicious party cable of doing a man-in-the-middle attack, they can present a valid certificate and fully impersonate the owner. For example, when Stripe started, they purchased the domain from another party, who had a valid stripe.com payment certificate for nearly a year. (https://www.certkit.io/blog/bygonessl-and-the-certificate-th...)
> Is CertKit a similar solution to Anchor Relay?
I hadn't heard about anchor relay before, thanks for the link!
CertKit is similar, but broader. Anchor says it sits between your ACME clients and the CA and simplifies the validation steps, which is super useful. But you still have to run ACME clients and have a bunch of automation logic running on your end.
CertKit IS the ACME client. You CNAME the challenge record to us and we do all the communication with the CAs and store/renew/revoke your certificates centrally. Your systems can pull (or be pushed) the certs they need via our API, then we monitor the HTTPS endpoints to make sure the correct cert is running. Its a fully-audited centralized certificate management.
This is not centralizing everything to Let's Encrypt. it's forcing everyone to use ACME, and many CAs support ACME (and those that don't probably will soon due to this change).
"Did not vote", and "not responsible", is definitely a take...
They could call their bluff. I would. The CA/browser forum made a mistake here. And they can only get away with it if the players involved comply.
Browers have an incentive to increase the complexity, good engineers would resist that.
This is just fear-mongering, legacy sites still need to update their tech and going fully automatic for cert renewals leads to less maintenance burden then renewing them manually.
Does that mean IP certificates will be generally available some time this week?
This vision still needs a several more developments to land before it actually results in an increment in user privacy, but they are possible:
I might add I've changed my mind a bit on this.
Decreasing Certificate Lifetimes to 45 Days
https://news.ycombinator.com/item?id=46117126
159 more comments available on Hacker News