Let's Encrypt Ended Free mTLS Client Certs on July 8 — the Last Ones Expire This Week

The last free mTLS client certificates on the public internet expire this week. On July 8, 2026, Let's Encrypt shut down its tlsclient ACME profile — the final pathway to a publicly trusted certificate with the TLS Client Authentication EKU — and with 90-day validity, the last certs it ever issued stop being valid in the first week of October. If anything you run still authenticates with a Let's Encrypt client cert, its renewal already stopped existing. What remains is the expiry date.

Here is the verdict before the mechanism: if your service-to-service mTLS runs on a mesh with its own CA, or your Let's Encrypt certs only ever terminate server TLS, you are unaffected and can stop reading. If any workload presents a Let's Encrypt certificate as a client credential — a cert-manager Certificate with a client auth usage on an ACME issuer, an app mounting an LE cert for peer authentication, a partner API integration, a vendor appliance — it breaks when the current cert expires, and there is no renewal behind it. The fix is to move client-auth issuance to a private CA or SPIFFE/SPIRE, and the audit takes five minutes.

The wind-down played out over fourteen months, which is exactly why it is catching people now: every deadline looked far away until the renewals quietly started coming back without the extension.

That last row matters because "just switch CAs" is the first idea everyone has. DigiCert turned the extension off by default back in October 2025, maximum public validity dropped to 200 days in March 2026, and as CertKit's Todd Gardner put it, finding a CA that still issues both extensions buys you months, not years. The public PKI is exiting the client-auth business on every front, on a fixed schedule.

Are you affected? The 5-minute audit​

Start with who is safe, because that is most readers. Server TLS is untouched — every cert terminating HTTPS on your ingress, gateway, or load balancer renews exactly as before. Service meshes that run their own CA are untouched too: Istio's istiod already issues short-lived workload certs to Envoy sidecars over SDS, Linkerd runs its own identity controller, and neither ever depended on a public CA for peer authentication. If your mTLS never leaves a mesh with a private identity plane, July 8 was a nonevent.

The affected population is everyone doing DIY mTLS on public certificates. That pattern was always a convenience hack — one ACME automation producing both your server certs and your client creds — and it shows up in more places than teams expect: microservices authenticating every call with a client certificate, partner API connections at banks and payment processors, device fleets, VPN concentrators, 802.1X wireless, and vendor appliances shipped with instructions to "install a public certificate" without saying which half of it did the work. Cisco has filed field notices on exactly this for Unified Border Element, Expressway, and Secure Network Analytics; the Expressway notice lists SIP business-to-business calls, federation, traversal zones, and cloud connectivity as what stops working, with the permanent fix shipping only in Expressway X15.5.

On Kubernetes, the concrete shape to grep for is a cert-manager Certificate requesting a client usage from an ACME-backed issuer:

kubectl get certificates -A -o yaml | grep -B15 "client auth"

Any match backed by a Let's Encrypt ClusterIssuer is holding a cert that either already renewed without the EKU or expires within days. Then check what your workloads actually present today:

openssl x509 -in client.crt -noout -ext extendedKeyUsage

If the output lists only TLS Web Server Authentication, that credential already stopped being a client cert at its last renewal. If it still lists TLS Web Client Authentication, check its notAfter — anything issued from the tlsclient profile dies this week.

One subtlety worth knowing: automated renewal masks the timeline. cert-manager renews at two-thirds of lifetime — day 60 of a 90-day cert — so classic-profile users lost the EKU at a routine spring renewal, while tlsclient holdouts kept working until now. Two identical-looking deployments can be months apart in when they break, which is why "it renewed fine" is not evidence of safety. Only the EKU list on the live cert counts.

What the failure looks like​

When the EKU is gone, the handshake fails at peer verification. The client still presents a structurally valid, unexpired, publicly chained certificate — and the server rejects it because the certificate is not authorized for client authentication. In Go services this surfaces as a peer-verification failure on the CertificateVerify step; nginx logs it as a client-cert verification failure; Java stacks throw a ValidatorException about key usage. The exact string varies, but the signature is consistent: mutual-TLS endpoints start rejecting previously working clients with no config change on either side, right after a renewal or an expiry.

That "no config change" property is what makes this read as an auth outage rather than a TLS problem. Dashboards show 401s or handshake failures, on-call reaches for the identity provider, and the actual cause is a missing extension on a certificate that renewed successfully by every monitor watching expiry dates. If your alerting watches notAfter but not EKU content — and almost everyone's does — add the extension check now, because the March 2027 deadlines will produce a second wave of the same failure for anyone on a commercial-CA stopgap.

It is also worth saying plainly what this is not: not a vulnerability, not a mis-issuance, not something to "wait and see" on. Let's Encrypt announced the change in May 2025 and staged it across four dates; the CA/Browser Forum and Chrome root program requirements behind it are not negotiable per-subscriber. The renewal you are waiting for is never coming.

Where client-auth issuance moves: the decision table​

There is no public replacement, so every path forward is some form of private issuance. The good news is the options are mature and the choice is mostly determined by where the workload already runs.

For Kubernetes teams, SPIRE deserves the extra paragraph because it is the one option that is strictly better than what died, not merely a substitute. A Let's Encrypt client cert proved "this client holds a cert for this DNS name," renewed every 60–90 days with no binding to the workload presenting it. A SPIRE-issued SVID proves "this is workload X on this node, attested by the platform just now," with lifetimes measured in hours and rotation handled through the Workload API.

Istio consumes SVIDs natively, and two plain pods can do mutual TLS with no sidecar and no mesh at all — the identity and cert plumbing without the control plane. That is the migration that ends with a stronger posture than the free certs ever gave.

The honest caveat runs the other way for everything outside Kubernetes. Standing up a private CA means taking on the work the public CA did for free: choosing lifetimes, getting the root onto every verifier, running revocation that actually works, and keeping an inventory — because a private CA with no inventory is, as Gardner writes, just an outage with a longer clock. Budget that toil explicitly instead of discovering it during the first rotation.

What your PaaS owes tenants this week​

If you operate a self-hosted PaaS with free automated TLS — the standard cert-manager plus Let's Encrypt recipe — some unknown fraction of your tenants built service-to-service auth on the assumption those certs work as client credentials. They will not file a ticket asking about EKUs. They will page you about auth failures, this week, on systems whose certificates all show valid.

The notice to send has three parts and fits in one message: what broke (public client-auth issuance is gone industry-wide, last LE client certs expire this week), the one check command (openssl x509 -ext extendedKeyUsage against whatever they present as a client), and the migration path you provide — because "run your own CA" is not an acceptable answer from a platform that previously made TLS free and invisible. That provisioned path is the actual product decision: a managed private-CA issuer tenants can point cert-manager at, or a SPIRE deployment whose Workload API their pods can consume.

Here the roadmap argument writes itself. If workload identity for AI agents is already on your roadmap — and for an AI-native PaaS it should be — the same SPIRE trust domain that attests agent sandboxes can issue the SVIDs that replace tenants' dying client certs. One attested-identity primitive absorbs both migrations instead of standing up a second system. The teams that framed SPIFFE as "agent infrastructure" and client-cert replacement as "PKI toil" will run two projects; the teams that see one workload-identity layer will run one.

The general rule, worth printing out: the public PKI authenticates servers to the world, and private PKI authenticates your workloads to each other. Fourteen months of staged deadlines just made that a fact instead of advice. Check your EKUs today — the certs expiring this week do not renew.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.