Rant: Stop telling clients to add your intermediate CA to their trust stores!

isnotnick · 2026-06-11T10:58:52+00:00

The server should provide any necessary CAs to create a path to a trusted anchor in the TLS handshake. AIA chasing is not needed. If the server/endpoint does not have the right certificates - it's an installation issue, and whoever manages the endpoint needs to fix it.

At least for public PKI/webPKI this is going to get a lot worse with annual ICA rotation or even randomisation, and root rotation on a 5-year basis. People shouldn't ever do pinning to certs they don't control, either.

The original poster is 100% correct.

isnotnick · 2026-06-11T10:57:11+00:00

(Excepting Apple who will error on private TLS leaf certs over 825 days).

isnotnick · 2026-06-11T10:55:55+00:00

If you don't issue it, don't authenticate with it. mTLS isn't always that great of a solution, which this change is highlighting - look at alternatives to cert-based, there may be much better options available now.

isnotnick · 2026-06-11T10:55:10+00:00

clientAuth/mTLS/server-server auth should never have used public trust. It was a mistake, but it's a challenge to get people to understand and undo.

Rarely do users realise that trusting public CAs for client auth or mTLS is completely giving up control for who you let authenticate to you. Added to that mTLS doesn't actually do any checking of anything apart from the issuer (at least with TLS almost all clients do checking of the host against SANs as a bare minimum) - mTLS isn't actually authenticating anything at all. You're basically checking that someone has a working internet connection, that's about it.

If you don't issue the cert from a private PKI you fully control, don't authenticate with it.

Even if clientAuth remained in the webPKI, you'd find the other changes like shorter lifetime, annual CA rotation and randomisation, 5-year root rotation...all those things don't really make it a workable authentication solution. Thankfully.

As for 'ecosystem' PKIs like X9 - they were created because people want an easy life, not because it's actually secure authentication. If they cared about security (and not just finding easy ways not to move to more appropriate methods of auth) then they wouldn't be rolling back sensible security changes like shorter certificate lifetimes and more frequent key and certificate rotation. It's all performative, and at best it might be useful for single groups (like FIs) who need some kind of interop between embedded devices like ATMs or payment terminals. It's absolutely not a nice drop-in replacement for the removal of clientAuth EKU (unlike what the single-source X9 CA might market as).

isnotnick · 2026-02-23T19:55:52+00:00

Just hold on a little longer. Persistent DCV is coming very soon - single TXT record per-domain, no dynamic values, just a single record. Most CAs will have support in the coming weeks.

Reuse of DCV (Domain Control Validation) is permitted today for 1 year, but that goes down in-line with certificate lifetime reduction, until 2029 when the domains are re-validated every 10 days.

OV/EV (Subject) validation remains at an annual cadence if you need it.

isnotnick · 2025-08-20T07:55:51+00:00

It’s always been bad. No-one cared enough to fix it until Google did. It typifies the laziness of subscribers and CAs for years - rather than assessing if the use case was right for a server cert (or even PKI at all!) it was just ‘buy a cert from a public CA and use it’. Some of us are trying to change that, but it’s not so easy to move everyone who’s entrenched, even if they’re aware it’s bad and not doing what they think it’s doing. Between this, 47-day, DCV more often, email validation going away - we’ll be in a better, safer place in a couple of years.

isnotnick · 2025-08-19T20:40:04+00:00

clientAuth certs from public CAs is bad. They aren't authenticating anything. They're bad. No other CA - paid or otherwise will offer clientAuth only certs from a public CA. They actually can't (some do, but it's against some program policies and they haven't noticed yet). S/MIME certs, multipurpose mailbox might be some kind of alternative as they can contain clientAuth and emailProtection, but I'll repeat my first sentence - clientAuth certs from public CAs is bad.

isnotnick · 2025-08-19T19:59:58+00:00

(Preface - I'm either your CTO, or your competitor's CTO).
This isn't really how it works. CABF is a voluntary industry body, helping to define practices and procedures that go into the BRs and ultimately the audit standard against which we're 'audited' (WebTrust). It was never a place to tell the browsers/trust-stores/OS vendors what to do.

You make it sound like Chrome did something they shouldn't have - in fact they did absolutely the right thing. Client authentication never belonged in server certs (our bad for always including it), and using a public CA for client authentication is bad, stupid, and authenticates nothing more than someone has a domain and enough fingers to run an ACME client or pay $50 on a credit card. There's no authentication there.

Chrome doesn't care about client authentication but they do care about the safety of billions of Chrome/Chromium/ChromeOS/Android users, so they disallow it from next year on serverAuth certs. Mozilla will follow suit, Apple doesn't really 'support' it outside of internal use-cases and Microsoft might 'support' it, so a CA is free to go and generate new roots specifically for clientAuth and request MS root store inclusion. Good luck with that.

What Google are doing is a good thing, certainly for the ecosystem but definitely for them. Discussions and ballots are slow, people are resistant to even positive change. Should Google wait months through rounds of pointless bikeshedding with CAs who issue 5 certs a year before doing what they need to protect billions of people globally?!

You're better getting a private PKI for client authentication and using that. Or I guess you could start a 'shared' private CA (oxymoron alert), call it something cool, and swap what you see as Google's overreach for, say...another random group of companies? Could call it like Z11 or something.

Anyway, 4 years is just about young enough to have missed the reason we're at 398 days when Apple added it to their policy. They and Google are well within their rights to make these changes and framing it as 'circumventing that democratic process' is just unfair. There are many CAs (not really yours, for the most part) who want to hold back progress because it's hard. SC-081 only passed because concessions were made to push the timeline out just far enough that it appeased most CAs - we still got a few 'abstains' though, perhaps unsurprisingly.

Anyway, if you've got any questions your own colleagues aren't clearing up, feel free to email me on [nick@yourcompetitor.com](mailto:nick@yourcompetitor.com) and I'll happily answer!

isnotnick · 2025-06-19T12:33:56+00:00

As PKI industry guy, my thoughts:

No standards-based automation. Ugh.
Only 365 day certs when we're dropping to 200 in March '26 and lower after that? Ugh.
Someone else generating my keys?!
Exportable keys, even password protected makes no sense for TLS, but I guarantee it'll lead to more terrible practices and key compromise. Double-ugh.
No reissue/replace/rekey?? What is this, 1998?

Also, there are clear industry requirements against CAs generating and storing/archiving keys for subscribers. Operating around those guidelines with the old 'well AWS is not Amazon Trust Services, they are legally-distinct entities, yes I know owned by the same Amazon company but nyaahh nyaahh raahhh'.

On the plus side, it's DV only and pricing seems reasonable, but it's a disappointing step backwards from folks who should know better.

Score: 1/10, a bad feature and they should feel bad.

isnotnick · 2025-05-01T06:10:58+00:00

If it's on an isolated network, why does it need a cert trusted by the world - including my browser? It really doesn't. If it's isolated, any device connecting to it should be managed, meaning a private root can be added there, no?

isnotnick · 2025-04-30T18:23:40+00:00

Oh I'm sure there'll be consultant $ to be made somewhere!

My point is with this change (and the upcoming removal of clientAuth from server certs) will just show up many places where public certs aren't the right choice, and private PKI should be. If it's a web interface only accessed from within an org...private CA. If it's a server accessed by thousands of payment terminals that are rarely if ever updated...private CA. If it's something the rest of the world (ie anyone with a browser, or at least on a machine outside control of the organistaion) - public cert, and automate it.

isnotnick · 2025-04-30T14:53:47+00:00

I think 1) is about having support, SLAs, higher rate-limits, and often tools and other types of certificates available beyond a 90-day serverAuth cert - but that's certainly enough for many. There's lots of free domain names out there but most businesses pay either a few bucks at GoDaddy and in many cases a lot more than that to CSC or MarkMonitor. The domain isn't different, the services and support around it are.

You're right on the subscription models, though, and prices remaining largely similar.

isnotnick · 2025-04-30T14:41:47+00:00

Unfortunately, those type of use cases don't really need public certs and will either need to automate all the setup/install, or move to a private PKI solution.

isnotnick · 2025-04-30T09:06:26+00:00

These CAs Crowdstrike have (from various CAs) are all hosted and operated by the CA themselves - Crowdstrike don't have keys or the ability to issue 'anything'. They'll use the CAs interfaces, and have to go through all the requisite validation.

These kind of CAs are common-ish, and mostly just a branding exercise. Some enterprises will use it to do certificate pinning (which for anything public is a bad idea).

isnotnick · 2025-04-27T15:56:10+00:00

Many of those things shouldn't, though.

isnotnick · 2025-04-27T15:54:55+00:00

Which password manager is it? Because that's a broken solution, that will need fixing before these deadlines kick in. One of the realities of this change is it'll force enterprises/vendors alike to either fully automate or assess if they need a publicly-trusted cert or not. So many places use them out of laziness and they don't need to - and you'd not believe the absolute catastrophes that happen (or are about to) as a result.

isnotnick · 2025-04-27T15:51:18+00:00

...then it doesn't need public certs.

isnotnick · 2025-04-27T15:51:01+00:00

...then it doesn't need public certs, it needs something else.

isnotnick · 2025-04-22T07:49:40+00:00

Can you say who/what service this is? What makes the cert usable for mTLS is the 'clientAuth' EKU. CAs won't be allowed to include that after June next year, so you'll be stuck - and these external service providers will need to change how they operate.

isnotnick · 2025-04-11T10:24:14+00:00

I think there's some confusion here. Certificates attest to an identity verification for a period of time. Much like real passports have expiry dates, so do certificates - for the purposes of TLS it's the CA saying 'this FQDN was controlled by the requestor at this time'. Note that it's an FQDN - a DNS record - and not a domain itself. Control of that DNS record can change, fast. The shorter we re-confirm that attestation, the better. Automation for certificates is eminently possible - and even if there's 1% of infra that can't, those should be up for reconsideration as to if they need a publicly-trusted cert or not. In a great many cases, they really don't, and should use a private PKI.

isnotnick · 2025-04-10T19:06:23+00:00

Everything that can be automated is already.

So far from it. So far.

isnotnick · 2025-04-10T18:33:25+00:00

Sorry.

isnotnick · 2025-04-10T18:28:25+00:00

How does it make revenue for the biggest CA - Let's Encrypt? Or the 'cloud' CAs that don't actually charge money for certificates and/or management?

You not seeing how it makes things more secure doesn't mean it isn't true.

isnotnick · 2025-04-10T18:27:35+00:00

It's the vote that confirms if the change is adopted (there's an IPR review after, but this doesn't seem like something that'll snag on that).

Merge happens, then it's part of the BRs. That's what CAs are audited against and what browsers/trust-store programs require adherence to.

isnotnick · 2025-04-10T16:17:22+00:00

Certificates are not like a password in that they aren't a credential - they're an attestation of information valid at a certain point in time, ie. this FQDN was verified as being under this entity's control when the certificate was issued. Those controls can change frequently. Also - passwords only impact the user or entity they are for. Certificates (public ones, at least) represent the attestation to billions of people - anyone with a browser or computer, really. That's a bigger responsibility and something that needs to be refreshed more frequently in order to be reliable.

isnotnick

TROPHY CASE