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.
It will make ACME the only viable option. I believe there is a second free ACME CA and other CAs will likely adopt ACME if they want to stay relevant.
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.
I'm quite surprised the CA/Browser Forum went for this.
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?
The CA/BF has a history of terrible decisions, for example 2020's "Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates".
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.
My case, I have to manage a portal for old tvs and those don’t accept the LE root certificate since they changed a couple of years ago. Unfortunately the vendor is unable to update the firmware with new certificates and we are sold
Yeah that LE root certificate change broke our PROD for about 25% of traffic when it happened. Everyone acts like we control our client's cert chains. Clients don't look at the failure and think "our system is broken - we should upgrade". They look at the connection failure and think "this vendor is busted - might as well switch to someone who works". I switched away from LE to the other free ACME provider for our public-facing certs after that.
Only for devices that do not allow you to patch the CA bundle as an aftermarket repair. Call your representative and demand Right to Repair legislation.
That is ... basically all of them? Other than general purpose desktop/laptop computers that is. Show me a TV or smartphone that does allow you to push new roots to it...
> If roots rotate often then we build the muscle of making sure trust bundles can be updated
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.
> 1. These might need to happen as emergencies if something bad happens
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?
The thing is even the most secure facilities need ingress and egress points.
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.
Chrome root policy, and likely other root policies are moving toward 5-years rotation of the roots, and annual rotation of issuing CAs.
Cross-signing works fine for root rotation in most cases, unless you use IIS, then it becomes a fun problem.
Free providers have limits and this new time limitation will also play into that as there will be many more certificates to renew.
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”.
Most every modern "big company" I have worked for is leveraging LetsEncrypt in some capacity where appropriate; some definitely more than others. I don't think you're completely wrong but I also think you're being a bit dismissive.
> 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.
Let's Encrypt isn't the only free ACME provider, you can take your pick from them, ZeroSSL, SSL.com, Google and Actalis, or several of them for redundancy. If you use Caddy that's even the default behavior - it tries ZeroSSL first and automatically falls back to Let's Encrypt if that fails for whatever reason.
> If you use Caddy that's even the default behavior - it tries ZeroSSL first and automatically falls back to Let's Encrypt if that fails for whatever reason.
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...
My bad, I misremembered the order. You're right that ZeroSSL requires credentials to get free certificates, but Caddy has special-case support for generating those credentials automatically provided you specify an email address in the config, so it's almost transparent to the user.
The ethical side is up to you, but in a strictly technical sense I don't think there's much that Google could do to intrude on your users privacy as a result of them issuing your SSL certificate, even if they wanted to. AIUI the ACME protocol never lets the CA see the private key, only the public key, which is public by definition anyway.
A more realistic concern with using Googles public CA is they may eventually get bored and shut it down, as they tend to do. It would be prudent to have a backup CA lined up.
> The ethical side is up to you, but in a strictly technical sense I don't think there's much that Google could do to intrude on your users privacy as a result of them issuing your SSL certificate, even if they wanted to.
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.
It absolutely has to do with ACME. There used to be CAs that would generate a service certificate including private key for you. This is obviously a terrible idea, but it is made impossible by ACME only allowing exchanging CSRs for certs.
It's more complicated than that. Apple (along with Google and Mozilla) basically held the CA's hostage. They started unilaterally reducing lifetimes. It was happening whether the CAB approved it or not.
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".
It's interesting that this is pretty much identical to the WHATWG/W3C situation: there is theoretically a standards body, but in practice it's defunct; the browsers announce what they will ship, and the "standards body" can do nothing but meekly comply.
The difference being that there's at least a little bit of popular dissatisfaction with the status quo of browsers unilaterally dictating web standards, whereas no one came to the defense of CAs, since everybody 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".
Uber is a morally bankrupt company that built its market position through criminal conduct, but everyone looked the other way because they hated the taxi industry even more.
Thanks for this history, I wasn't aware. It's an interesting point that if this is happening anyways by Apple's fiat, it's in the legacy CAs' interest to even further accelerate the mandatory timeline, so they can pivot to consulting services for their existing customers.
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.
I think it's more broadly "browsers vs. CAs", I think the balance of power shifted sharply after the Symantec distrusting, and I think very few people on HN would prefer the status quo ante of that power shift if we laid out what it meant.
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.
That was an interesting read, thanks! Two questions:
- What is the problem with stale certificates if a domain changes hands? It seems to me that whether they renew the certificate or not, the security situation for the user is still the same, no?
> What is the problem with stale certificates if a domain changes hands?
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.
Except this is going the wrong way. We should be discouraging frequent domain ownership changes not making them easier. New owners getting visibility into traffic meant for the old owners is as much if not a bigger problem.
Certificate rotation/renewal has been the biggest headache of my IT career. It’s always after the fact. It’s always a pain point. It’s always an argument with accounting over costs. It sucks. I’m glad ACME exists but man this whole thing is a cluster fuck.
Whole IT teams are just going to wash their hands of this and punt to a provider or their cloud IaaS.
Man, I agree. The whole thing sucks so much. We started building a centralized way to do this internally last year to get better visibility into renewals and expirations:
Cool but for us, this kind of thing is better solved closer to the edge with automation like Caddy server that does this for us while also being our ingress proxy for all those domains.
I want Apache to do this natively.
I want nginx to do this natively.
I want tomcat to do this natively.
I want express to do this natively.
Every single http server punts on TLS as an afterthought of supply me your private and public key and I’ll do it. Sure there are modules now for those servers for ACME but this process is still old school Web 1.0 deployment logic.
I've built something similar, not as cool as certkit, but using acme.sh i generate a wildcard and then internally my servers can pull the wildcard generates an md5 so i can track if it changes, put the certs where they need to be and restart the services they need that use it. Linux and Windows. It works.
It's fine for fintechs and social accounts to require SSL, but do blogs really need certs? You know what blogs I'm reading from my DNS requests anyway. I doubt anyone is going to MITM my access to an art historian's personal website. There is zero need for security theater here.
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.
> I doubt anyone is going to MITM my access to an art historian's personal website.
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.
This is a popular refrain from folks hosting read-only sites.
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).
How do you protect your physical letters from being opened by unauthorized parties along the delivery chain? You don't for the most part because we have made it a very series crime to do that. We could have done the same to badly behaving ISPs. Instead browsers have chosen to make planned obsolescence a requirement for the web.
Making it a crime is very regional, and enforcement is basically non existent. But opening it is not the problem here.
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.
supply chain - if you put some 3rd party script link, ad, tracking or even just update dependencies to a bad version like the npm packages hack on your page, TLS won't save you if the service or dependency gets hacked
The biggest culprit is the ad network script. Whether it’s a script tag, an iframe, an image pixel, it’s basically allowing the browser to send your visit event and user agent information (or the chrome updated headers) to that 3rd party and if it’s using jsonp, can callback a function on the page to inject malware that can take over your browser. Ask me how I know.
I agree. Fortunately for blogs, we still have an option - make sure your website is accessible via HTTP / port 80. This has the extra advantage that your website will continue to work on older tech that doesn't support these SSL certs. It will even be accessible to retro hardware that couldn't attempt decoding SSL in the first place.
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.
Unfortunately this means that now your pages are available at multiple URLs, one which won't work everywhere - and you have no control over what URL people will share.
If you HTTP between you and the internet, yes, yes you absolutely need SSL. It’s like “If it’s hot out, do I really need to wear shorts or pants at all?” Yes. The answer is always yes.
It started being enforced only after major USA ISPs started injecting malware into every HTTP page. If it was a theoretical concern I might agree with you, but in reality, it actually happened which overrules any theoretical arguments. Also, PRISM.
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.
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.
> 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.
The good news is that the CAs signed their own death warrant with this change. If switching to ACME is more or less mandatory, what purpose do paid certificates serve? Your options are to use LE, switch to non-CA-issued encryption, or drop encryption entirely.
You assume it’s just the certs being purchased - and not support, SLAs, other related products, management platforms, private PKI and more. If all you do is public TLS, sure, that might be an issue.
Secure context is only required for features that are somehow privacy- or security-sensitive. Some notable features are on the list, but you can absolutely have a modern site that doesn't rely on any of these.
Paid certs are valid for 1-year from the $$ CAs. LE certs are only good for ~3-4 months before they have to be reissued. If there's no easy way to do an automated ACME setup to handle the renewal, being able to defer that for a year is worth the $20 or $70 for a wildcard.
If paid certs drop in max validity period, then yeah, zero reason to burn money for no reason.
Nginx and Apache are free and both can be trivially automated with ACME bot. Both can be used to set up a reverse proxy in front of legacy sites or applications.
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).
> IMO this is a policy change that can Break the Internet
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.
>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.
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.
I have been saying it since the beginning that we are centralizing all the power of the internet to one organization and that this a bad thing, yet I get downvoted every time. One organization is going to have a say on whether or not you can have a website on the internet, how is this objectively a good thing?
I'll upvote you for at least asking the question. But you get downvoted because your premise is wrong.
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.
Maybe you get downvoted because this isn't centralizing all the power of the internet to one organization rather than being downvoted because people don't have an issue with that.
The CA/Browser forum has massive power over the web whether you like it or not, because they make the browsers. And make no mistake, it's the browser representatives that are the most aggressive about tighter security and shorter certificate lives.
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.