TLS certificate lifetimes will officially reduce to 47 days

It's a decision by Certificate Authorities, the ones that sell TLS certificate services, and web browser vendors. One benefits from increased demand on their product, while the other benefits by increasing the overhead on the management of their software, which increases the minimum threshold to be competitive.

There are security benefits, yes. But as someone that works in infrastructure management, including on 25 or 30 year old systems in some cases, it's very difficult to not find this frustrating. I need tools I will have in 10 years to still be able to manage systems that were implemented 15 years ago. That's reality.

Doubtless people here have connected to their router's web interface using the gateway IP address and been annoyed that the web browser complains so much about either insecure HTTP or an unverified TLS certificate. The Internet is an important part of computer security, but it's not the only part of computer security.

I wish technical groups would invest some time in real solutions for long-term, limited access systems which operate for decades at a time without 24/7 access to the Internet. Part of the reason infrastructure feels like running Java v1.3 on Windows 98 is because it's so widely ignored.

Or, equivalently, it's being pushed because customers of "big players", of which there are a great many, are exposed to security risk by the status quo that the change mitigates.

It makes the system more reliable and more secure for everyone.

I think that's a big win.

The root reason is that revocation is broken, and we need to do better to get the security properties we demand of the Web PKI.

"Suffer" is a strong word for those of us who've been using things like Let's Encrypt for years now without issue.

Unless I misunderstood, GP mentions that the problem stems from WebPKI's central role in server identity management. Think of these cert lifetimes as forcefully being signed out after 47 days of being signed in.

> easier for a few big players in industry

Not necessarily. OP mentions, more certs would mean bigger CT logs. More frequent renewals mean more load. Like with everything else, this seems like a trade-off. Unfortunately, for you & I, as customers of cert authorities, 47 days is where the now the agreed cut-off is (not 42).

Like Apple case. Apple already ask their developer to re-sign the app every 7 days. It should not be the problem.

There's no such thing as an ideal world, just the one we have.

Let's Encrypt was founded with a goal of rapidly (within a few years) helping get the web to as close to 100% encrypted as we could. And we've succeeded.

I don't think we could have achieved that goal any way other than being a CA.

In an ideal world where we rebuilt the whole stack from scratch, the DNS system would securely distribute key material alongside IP addresses and CAs wouldn't be needed. Most modern DNS alternatives (Handshake, Namecoin, etc) do exactly this, but it's very unlikely any of them will be usurping DNS anytime soon, and DNS's attempts to implement similar features have been thus far unsuccessful.

No they should not

DANE is the way (https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...)

But no browser have support for it, so .. :/

This is a great question. If we don't have CAs, how do we know if it OK to trust a cert?

Are there any reasonable alternatives to CAs in a modern world? I have never heard any good proposals.

In an ideal world we could just trust people not to be malicious, and there wouldn't be any need to encrypt traffic at all.

How relevant is that since we don't live in such a world? Unless you have a way to get to to such a world, of course, but even then CAs would need to keep existing until you've managed to bring the ideal world about. It would be a mistake to abolish them first and only then start on idealizing the world.

CAs exist on the intersection of reality (far from ideal) and cryptography.

What alternatives come to mind when asking that question? Not being in the PKI world directly, web of trust is what comes to mind, but I'm curious what your question hints at.

This one?

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

I don't see why it would; the same basic requirements around CT apply regardless of certificate longevity. Any CA caught enabling this kind of MITM would be subject to expedient removal from browser root programs, but with the added benefit that their malfeasance would be self-healing over a much shorter period than was traditionally allowed.

lol no? lower cert times still extend the root certificates that are already trusted. It is not a noticeable thing when browsing the web as a user.

A MITM cert would need to be manually trusted, which is a completely different thing.

It's all relative. A 47-day cycle increases the load, but a 48-hour cycle would increase it substantially more.

Much of the HSM load within a CA is OCSP signing, not subscriber cert issuance.

> Our internally provided certs of various CAs have a TTL of 72 hours and should be renewed every 48 hours.

Do you promise to come back and tell us the story about when someone went on vacation and the certs issued on a Thursday didn't renew over the weekend and come Monday everything broke and no one could authenticate or get into the building?

Some of this rhymes with Colm MacCárthaigh's case against mTLS.

https://news.ycombinator.com/item?id=25380301

This has been our issue too. We've had mandates for rotating OAuth secrets (client ID & client secret).

Except there are no APIs to rotate those. The infrastructure doesn't exist yet.

And refreshing those automatically does not validate ownership, unlike certificates where you can do a DNS check or an HTTP check.

Microsoft has some technology that next to these tokens they also have a per-machine certificate that is used to sign requests, and those certificates can't leave the machine.

As is already described by the comment thread we're replying in, "internal use" and "HTTPS" are very compatible. Corporations can run an internal CA, sign whatever internal certs they want, and trust that CA on their devices.

CAs fucking up every once in a while is inevitable. It is impossible to write guaranteed bug-free software or train guaranteed flawless humans.

The big question is what happens when (not "if") that happens. Companies have repeatedly shown that they are unable to rotate certs in time, to the point of even suing CAs to avoid revocation. They've been asked nicely to get their shit together, and it hasn't happened. Shortening cert lifetime to force automation is the inevitable next step.

The browser policies are set by the same entities doing the CAB voting, and basically every prior change around WebPKI has only been enforced by browsers for CAs in the browser root trust stores. Which is exactly what's defined in this CAB vote as well.

Why would browsers "most likely" enforce this change for internal CAs as well?

Why would they? The old certificates will expire and the new ones will have short lifespans. Web browsers do not need to do anything.

That said, it would be really nice if they supported DANE so that websites do not need CAs.

'Most likely' - with the exception of Apple enforcing 825-day maximum for private/internal CAs, this change isn't going to affect those internal certificates.

What about something like step-ca? I got the free version working easily on my home network.

https://smallstep.com/docs/step-ca/

> A lot more work

'ipa-client-install' for those so motivated. Certificates are literally one among many things part of your domain services.

If you're at the scale past what IPA/your domain can manage, well, c'est la vie.

Sure. The point is, don't bother letting the apps themselves do TLS termination. Too much work that's better handled by something else.

F5s don't support ACME, which has been a pain for us.

Companies have software to manage this for you. We utilize https://www.cyberark.com/products/machine-identity-security/

You could always ask for wildcard for internal subdomain and use that instead so you will leak your internal FQDN but not individual hosts.

> Or request a certificate over the public internet, for an internal service. Your hostname must be exposed to the web and will be publicly visible in transparency reports.

That doesn't seem like the end of the world. It means you shouldn't have `secret-plans-for-world-takeover.example.com`, but it's already the case that secret projects should use opaque codenames. Most internal domain names would not actually leak any information of value.

In a production environment with customer data?

It's 100% possible today to get certs in segmented networks without a new ACME challenge type: https://anchor.dev/docs/public-certs/acme-relay

(disclamer: i'm a founder at anchor.dev)

I'd set that up the second it becomes available if it were a standard protocol. Just went through setting up internal certs on my switches -- it was a chore to say the least! With a Cert Template on our internal CA (windows), at least we can automate things well enough!

Acme dns challenge works for things that aren't webservers.

For the other case perhaps renew the cert at a host allowed to do outside queries for the dns challenge and find some acceptable automated way to propagate an updated cert to the host that isn't allowed outside queries.

And may the devil help you if you do something wrong and accidentally trip LetsEncrypt's rate limiting.

You can do nothing except twiddle your thumbs while it times out and that may take a couple of days.

If you want to be a public root CA, so that every browser in the world needs to trust your keys, you can do all the lifting that the browsers are asking from public CAs.

Why do you want this when there are wildcard certificates? That's how the hyperscalers do it as well. Amazon doesn't have a separate certificate for each s3 bucket, it's all under a wildcard certificate.

TOFU equates to "might as well never ask" for most users. Just like Windows UAC prompts.

MITM scenarios are more common on the 2025 Internet than passive attacks are.

SSH TOFU is also deeply problematic, which is why cattle fleet operators tend to use certificates and not piecewise SSH keys.

ssh server certificates should not be TOFU, the point of SSH certs is so you can trust the signing key.

TOFU on ssh server keys... it's still bad, but less people are interested in intercepting ssh vs tls.

You don't have to TOFU SSH server keys, there is a DNSSEC option, or you can transfer the keys via a secure path, or you can sign the keys with a CA.

>I mean, we do TOFU for SSH server certificates and nobody really seems to bat an eye at that.

Mostly because ssh isn't something most people (eg. your aunt) uses, and unlike with https certificates, you're not connecting to a bunch of random servers on a regular basis.

TOFU is not less secure than using a certificate authority.

Both defend against attackers the other cannot. In particular, the number of machines, companies and government agencies you have to trust in order to use a CA is much higher.

It's an unauthenticated encrypted connection, so there's no way for you to know whose keys you're using. The attacker can just tell you "Hi, I'm the server you're looking for. Here's my key." and your client will establish a nice secure, encrypted connection to the malicious attacker's computer. ;)

They MITM the key exchange step at the beginning, and now they do have the keys. The thing that prevents this in TLS is the chain of signatures asserting identity.

Connections never start as encrypted, they always start as plain text. There are multiple ways of impersonating an IP even if you don't control DNS, especially if you are in the same local network.

When I use a service over TLS on a network I don't trust, the premise is that I only will trust the connection if it has a certificate from a handful of companies trusted by the people who wrote the software I'm using (my browser/client and/or my operating system) to only issue said certificates to people who are supposed to have them (which these days is increasingly defined to be "who are in control of the DNS for the domain name at a global level", for better or worse, not that everyone wants to admit that).

But like, no: the free Wi-Fi I'm using can't, in fact, MITM the encryption used by my connection... it CAN do a bunch of other shitty things to me that undermine not only my privacy but even undermine many of the things people expect to be covered by privacy (using traffic analysis on the size, timing, or destination of the packets that I'm sending), but the encryption itself isn't subject to the failure mode of SSH.

> I disagree. Think about every time you use a service (website, email, etc.) you've used before via a network you don't trust (e.g. free WiFi).

Hm? The reason I do use those services over a network I don't trust is because they're wrapped in authenticated, encrypted channels. The authenticated encryption happens at a layer above the network because I don't trust the network.

But isn't that exactly the previous posters point? Free WiFI someone can just MITM your connection, you would never know and you think its encrypted. Its the worst possible outcome. At least when there's no encryption browsers can tell the user to be careful.

It tells you the entity which holds the key is the actual owner of myfavouriteshoes.com, and not just a random guy operating the free Wi-Fi hotspot at the coffee shop you're visiting. If you don't care about that then why even bother with encryption in the first place?

at least it's not evil-government-proxy.com that decided to mitm you and look at your favorite shoes.

What? I work in this field and I have no idea what you mean. (I get the abbreviations like authz and pk, but not how "encrypting everything" and "posting links" is supposed to remove the need for authentication)

DANE is a TLS with too-big-to-fail CAs that are tied to the top-level domains they own, and can't be replaced.

Separation between CAs and domains allows browsers to get rid of incompetent and malicious CAs with minimal user impact.

You can use multiple DNS providers at once to catch that situation. You can have some sort of signing scheme where each authoritative server would sign something in turn to establish a chain of trust up to the root servers. You can use encrypted DNS, even if it is relying on traditional TLS certificates, but it can also use something different for identity verification, like having you use a config file with the public key embedded in it, or a QR code, instead of just an address.

I've said it up-thread, but never ever never never pin to anything public. Don't do it. It's bad. You, and even the CA have no control over the certificates and cannot rely on them remaining in any way constant. Don't do it. If you must pin, pin to private CAs you control. Otherwise, don't do it. Seriously. Don't.

> That doesn't particularly matter; if someone takes over the domain but doesn't have a leaked key, they can't sign requests for the domain with my cert. It takes a leaked key for this to turn into a vulnerability.

It does, if someone gets temporary access, issues a certificate and then keeps using it to impersonate something. Now the malicious actor has to do it much more often, significantly increasing chances of detection.

I just downloaded one of DigiCert's CRLs and it was half a megabyte. There are probably thousands of revoked certificates in there. If you're not checking CRLs, and a lot of non-browser clients (think programming languages, software libraries, command-line tools, etc.) aren't, then you would trust one of those certificates if it was presented to you. With certificate lifetimes of 47 days instead of a year, 87% of those revoked certificates become unusable regardless of CRL checking.

Also certificate transparency is moving to a new standard (sunlight CT) that has immediate merges. Google requires maximum merge delay to be 1 minute or less, but they've said on google groups that they expect merges to be way faster.

The log is not really for real time use. It’s to catch CA non-compliance.

Mostly this. Today of a big CA is caught breaking the rules, actually enforcing repairs (eg prompt revocation ) is a hard pill to swallow.

How do you enjoy being dependent on a 3rd party (even a well intentioned one) for being on the internet?

Let's Encrypt... Cloudflare... useful services right? Or just another barrier to entry because you need to set up and maintain them?

I dunno. Self-hosting w/o automation was feasible. Now you have to automate. It will lead to a huge amount of link rot or at least something very similar. There will be solutions but setting up a page e2e gets more and more complicated. In the end you want a service provider who takes care of it. Maybe not the worst thing, but what kind of security issues are we talking about? There is still certificate revocation...

It makes end to end responsibility more cumbersome. There were days people just stored MS Frontpage output on their home server.

Ofc, but you have to be quite techsavy to know this and to set this up. It's also cumbersome in many low-tech situations. There is certificate revocation, I would really like to see the threat model here. I am not even sure if automation helps or just shifts the threat vector to certificate issuing.