Why Public CAs No Longer Issue Client Certificates

Something broke, and nobody announced it

Here's a scenario that played out in at least a dozen Slack channels this month: an engineer renews their Let's Encrypt certificate. The ACME script runs clean. The new cert looks fine. Then their mTLS connections start dropping. Clients can't authenticate. The cert is valid for server TLS, but the TLS Client Authentication EKU is gone. Just... gone. No deprecation warning in the logs, no flag in the ACME response. The capability was silently removed from the default certificate profile on February 11th.

If you haven't hit this yet, you probably will on your next renewal. And if you're wondering why Let's Encrypt would do this, the short answer is: they didn't really have a choice.

Chrome made the call

Google's Chrome Root Program, which effectively decides which CAs the world's most-used browser will trust, now requires that client authentication and server authentication live in completely separate PKI hierarchies. The deadline is June 2026. Any CA that doesn't comply gets pulled from Chrome's trust store, which for a public CA is basically a death sentence.

The reasoning makes sense if you think about it from Chrome's perspective. A certificate that tells a browser "yes, this really is example.com" is doing something completely different from a certificate that tells your API gateway "this service is allowed to call me." Cramming both functions into one cert creates ambiguity, and ambiguity in identity systems is where exploits live. Chrome decided to kill the ambiguity.

Fair enough. But the downstream consequences are significant, and a lot of teams are only now discovering them.

The dates that matter

Let's Encrypt laid out a three-phase plan. The first phase has already happened, which is why people are running into this now:

And here's the part that a lot of people are missing: this isn't a Let's Encrypt policy. It's a Chrome Root Program requirement. Every public CA that wants to stay in Chrome's trust store will need to make the same split. Let's Encrypt just moved first.

So who does this actually affect?

If your certs only face web browsers, you're fine. Nothing changes for standard HTTPS. But a surprising number of production systems have been leaning on public CA certs for things those certs were never really meant to handle:

People figured this out the hard way

A Hacker News thread about the Let's Encrypt announcement pulled in 54 comments, mostly from engineers who'd either already been burned or could see it coming. The discussion eventually converged on a point that would've been controversial a few years ago but now reads as self-evident:

The Reddit threads are more visceral. r/sysadmin and r/devops have been filling up with a specific kind of post: someone renewed their certs, changed nothing else, and their service-to-service auth stopped working. The ACME logs look clean. The cert validates fine in a browser. But the client auth handshake fails, and there's no helpful error message to point you in the right direction. You just have to know that the EKU changed. A lot of people didn't know.

And the timing couldn't be worse

Two weeks before Let's Encrypt's change started biting, the CA/Browser Forum's SC-081 ballot kicked in. As of March 15, public TLS certificates max out at 200 days. That drops to 100 next March. Then 47 days by 2029. So renewals are happening more often, which means more teams are going to hit this sooner, and the old trick of just hanging onto a cert that still has the right EKU gets less viable with every cycle.

Public CAs are narrowing to one job: making browsers happy. If that's not your only use case, you need a different plan.

The obvious answer (and why it's not as simple as it sounds)

Ask anyone in the HN thread or the Reddit discussions and they'll tell you the same thing: run a private CA. And they're right. A private CA doesn't answer to the Chrome Root Program. You choose what EKUs to include, what lifetimes to set, what issuance policies to enforce. Need a cert that handles both client and server auth? Issue one. Need certs that expire in four hours? Go ahead. Nobody's going to revoke your root because you didn't split your hierarchies the way Google wanted.

But "run a private CA" glosses over the hard part. A CA is the root of trust for every certificate it issues. If you get the implementation wrong, you've traded a policy problem for a security problem. Here's what actually matters when you're evaluating this move:

What this really is

Zoom out from the specifics of EKUs and ACME profiles and the picture gets clearer. For about a decade, public CAs accidentally served double duty. They were built for browser trust, but because their certs happened to include the Client Authentication EKU, people used them for machine identity too. It worked well enough that nobody questioned it. The Chrome Root Program has now made it explicit that this was a side effect, not a feature, and the side effect is being removed.

If you see this coming and plan for it, the transition is manageable. You have until July with a workaround, and the architectural patterns are well-understood. If you find out about it because your mTLS connections are failing in production at 2am, the conversation goes very differently.

Where this leaves you

Public CAs aren't scaling back on client auth. They're done with it. The mandate comes from the browsers, the timeline is locked, and there is no version of this where it gets reversed. If your infrastructure relies on client certificates for any purpose, the public CA path is closing and it won't reopen.

The good news, if you want to call it that, is that the engineering community has already converged on the answer. Private CA. Your trust, your policies, your infrastructure. The less-good news is that July is three months away, and a lot of teams haven't started.