It wasn't just the browsers. Some CAs supported this for a long time, and even directly endorsed the ballot. You're not wrong about the browsers having 'the power', but then again - they are the representatives of billions of relying parties, so it's expected.

mTLS is going to be a problem soon, arguably bigger than this lifetime reduction. Most server certs today have clientAuth EKU and can be used for mTLS. That stops next year.

It took me awhile to dig up evidence for this, but the closest I can find is that subordinate CA certificates will no longer be allowed to have id-kp-clientAuth EKU [1], however this restriction does not apply to leaf certificates.

[1]: https://googlechrome.github.io/chromerootprogram/#321-applic...

It applies to leaf certs too. (Full disclosure - I work in the industry, so know this well). After June 15th, 2026 - no leaf certs with serverAuth and clientAuth. Mind you, client authentication with public certificates is a bad idea anyway, but I appreciate many people do and it's just been 'the way' for many years. This is why I think it's going to hurt if folks don't realise soon and start to plan.

I cannot find any hard evidence of this claim -- I don't have reason to believe you're making it up, but I also would expect this change to be more widely announced. The best I can find is some discussion by Let's Encrypt staff that the roots want to stop issuing clientAuth-enabled leaf certificates eventually. However, there haven't been any hard timelines established because (at least) some mail servers in particular are using ___domain-validated public certificates for opportunistic mTLS.

I've scoured the CA/Browser Forum BRs and ballots, Chrome Root Store policies, and CCADB policies, and can't find mention of this coming restriction.

It's a Chrome policy: https://googlechrome.github.io/chromerootprogram/ 3.2.1 (item 2).

In case it helps - am the CTO of a large CA, so (un)fortunately aware of what's happening and when.

Wow, I completely missed bullet 2. It's quite clear:

    All corresponding unexpired and unrevoked subscriber (i.e., TLS server authentication) certificates issued on or after June 15, 2026 MUST include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth.

Thanks!

That isn’t at all true.

Don't forget the lede buried here - you'll need to re-validate control over your DNS names more frequently too. Many enterprises are used to doing this once-per-year today, but by the time 47-day certs roll around, you'll be re-validating all of your ___domain control every 10 days (more likely every week).

This. Also, re-evaluate how many places you actually need public trust that the webPKI offers. So many times it isn't needed, and you make problems for yourself by assuming it does. I have horror stories I can't fully disclose, but if you have closed networks of millions of devices where you control both the server side and the client side, relying on the same certificate I might use on my blog is not a sane idea.

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.

There's not really a better option if you need your urls to work with public browsers and also an app you control. You can't use a private CA for those urls, because the public browsers won't accept it; you need to include a public CA in your app so you don't have to rely on the user's device having a reasonable trust store. Including all the CAs you're never going to use is silly, so picking a few makes sense.

You don't need both of those things. Give your app a different url.

Why should I trust a CA that has no control over the certificate chains?

Because they operate in a regulated, security industry where changes happen - sometimes beyond their control?

Repeating it doesn’t make it any more true. Cert providers publish their root certs, you pin those root certs, zero problems.

Then the CA goes away, like Entrust. Huge problems. I speak (sadly) from experience.

They rotate those often enough.

Certificate pinning to public roots or CAs is bad. Do not do it. You have no control over the CA or roots, and in many cases neither does the CA - they may have to change based on what trust-store operators say. Pinning to public CAs or roots or leaf certs, pseudo-pinning (not pinning to a key or cert specifically, but expecting some part of a certificate DN or extension to remain constant), and trust-store limiting are all bad, terrible, no-good practices that cause havoc whenever they are implemented.

Ok, but what's the alternative?

Support for cert and CA pinning is in a state that is much better than I thought it will be, at least for mobile apps. I'm impressed by Apple's ATS.

Yet, for instance, you can't pin a CA for any ___domain, you always have to provide it up front to audit, otherwise your app may not get accepted.

Doesn't this mean that it's not (realistically) possible to create cert pinning for small solutions? Like homelabs or app vendors that are used by onprem clients?

We'll keep abusing PKI for those use cases.

I think if you're going to pin, pin to something you control. If it's an API endpoint, you can use a private CA and have the app trust your root, and pin to that. Same end result, but you're not going to be stuck if a third-party you have nothing to do with decides that some part of the hierarchy needs to change.

That's the exact opposite of what I'm referring to.

There is a client that has a self hosted web service. Or a SaaS but under his own ___domain.

There is a vendor that provides nice apps to interact with that service. Vendor distributes them on his own to stores, upgrades etc.

Clients has no interest in doing that, nor any competencies.

Currently there is no solution here: Vendor needs to distribute an app that has Client's CAs or certs built in (into his app realese), to be able to pin it.

I've seen that scenario many times in mid/small-sized banks, insurance and surrounding services. Some of these institutions rely purely on external vendors and just integrate them. Same goes for tech savvy selfhosters - they often rely on third party mobile apps but host backends themselves.

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

Curious as to why it’s that many inserts? The whole CT ecosystem has about 30-40,000 new certs/precerts a minute IIRC). Love merkelmap though!

There’s backlog I still need to process :)

Just to be clear, the whole incident covered over 80,000 certificates. The TRO was applicable to only those of one subscriber - just over 70 certificates, yet caused the revocations of all 80k+ to be delayed.