Hacker News Reader

Comment by btown | Hacker News Reader

The certificate lifetime decrease, to 45 days, was discussed in: https://news.ycombinator.com/item?id=46117126

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.

View on HN

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?

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.

Roots for all CAs are going to be rotating much more frequently now. Looking to be every 5 years.

I'd be interested in hearing more - do you have a source for this?

Seems to me CAs have intermediate certificates and can rotate those, not much upside to rotating the root certificates, and lots of downsides.

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.

What an absolute pain in the ass for a mediocre increase in security.

The upside to rotating roots is:

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.

> 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.

5 years also is a step not a destination

Sounds more like a detour across hot coals that doesn't get us anywhere closer to the destination.

> 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.

Sounds like planned obsolescence if devices stop working after 5 years or less.

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...

And your clients are right. The "security" community's wanton disregard for backwards compatibility is abhorrent.

Well, how the vendor was going to apply other security updates if they cannot update their basic security trust store?

If the vendor is really unable to update, then it's at best negligence when designing the product, and at worst -- planned obsolescence.

Yeah, participation in web tls requires the ability to regularly update your server and client code.

Nothing stays the same forever, software is never done. It’s absurd pretend otherwise.

1. Ship the product with automatic updates delivered over https

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.

The real solution is making your shit modifiable by the client.

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.

> I'm quite surprised the CA/Browser Forum went for this.

The CA folks and the Browser folks may have had differences of opinions.

You think? :)

Yes. Mozilla presumably want this rent-seeking industry of useless middleman to disappear.

Downvoted by rent-seeking useless middlemen, presumably

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.

How is the CA/B forum relevant for code signing certificates?

How are they not? :)

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.

They won't adopt Acme, as once a customer adopts it, the effort to transition to a new (free) provider is almost zero.

I expect they will introduce new, "more secure", proprietary methods, and ride the vendor lock-in until the paid certificate industries death.

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.

I hope everyone will adopt ACME I still have to send CSR to the customers and they send me cert back. It is okish once a year.

There are 2 and GTS is also technically free. Just hard to use.

> 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.

LE has some gnarly rate limiting rules, so I use ZeroSSL. Works out great for my purposes.

That's the reason I switched. I had an issue where a path was not mounted correctly and we blew through our limits.

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...

Hm, it's supposed to be https://letsencrypt.org/docs/integration-guide/ - but it looks like the link is broken. I'll fix it.

How are all those free CAs financed?

Let's Encrypt is a non-profit funded by donations and corporate sponsorships.

ZeroSSL, SSL.com and Actalis offer paid services on top of their basic free certificates.

Google is Google.

Ah, that makes sense. Thanks!

> 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)?

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.

Ah, I see

> and paid for with your privacy (and probably your website user's privacy too)?

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.

> 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.

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...

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.

https://caddy.community/t/using-zerossls-acme-endpoint/9406

Correction: the default behavior is to use Let's Encrypt alone, but if you provide an email then it's Let's Encrypt with fallback to ZeroSSL.

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".

I wrote a bunch about this recently: https://www.certkit.io/blog/47-day-certificate-ultimatum

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.

Things are better now.

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.

The CA industry is the new taxi industry.

Thanks. This is an informative piece.

Which AI did you use for writing it? It's pretty good.

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?

- Is CertKit a similar solution to Anchor Relay? (https://anchor.dev/relay)

The problem is that the old owner still has a valid certificate for some period of time.

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.

> 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.

Not quite true - some CAs were not 'held hostage' - some agree with the changes and supported them. See the endorsers for SC-081.

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.

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.

Without TLS on your blog anyone in the middle can trivially inject malware to all your readers.

it still can, just add some 3rd party javascript or unpatched backend app

How do you inject anything into a TLS served webpage as an equipment-in-between without the cert's key?

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.

You think that’s base64 you’re reading? Hmm. :)

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.

> 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.

> PRISM works fine to recover HTTPS-protected communications

Source:

https://en.wikipedia.org/wiki/PRISM

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.

They also do wiretaps, and the exact name of the program is not relevant.

Oh it’s way more pervasive.

That’s just what the public knows. It goes far beyond that.

Most of the good projects in DoD space have Star Wars names. BESPIN, JEDI, etc. PRISM is a mechanism, one aspect of a much larger machine.

> 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.

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.

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.

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.

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:

We're doing a beta of it for some other groups now. https://www.certkit.io/

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.

Note the timeline. Nothing's changing soon.

> 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.

You have a different definition of soon than me.

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.

New web features are https-only by default, since a few years ago. So if your site uses any recent APIs, dropping encryption is not an option.

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.

Securing your communications is required to mitigate against main in the middle attacks.

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.

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.

The $$ CAs will soon only issue 45-day certs, because that's all that browsers will accept.

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.

“Browser makers” in this context generally just means Google, though this particular proposal came from Clint Wilson from Apple.

Google calls the shots and the others fall in line.

This is Google's doing, just like the Client Authentication EKU debacle.

> But Let's Encrypt is not responsible for this move, and did not vote on the ballot.

"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.

Will the browsers only be forcing the 47 day limit for publicly-trusted CAs?

Yes.

>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?

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.

I have the feeling that this is much more about control than it is about security.

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.

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.

Reply on news.ycombinator.com