Originally published at https://monstermegs.com/blog/ssl-certificate-client-authentication/
If your infrastructure relies on SSL certificate client authentication to let services verify each other's identity, you now have a firm deadline to meet. Let's Encrypt – the most widely used certificate authority on the internet – will stop issuing certificates containing the TLS Client Authentication Extended Key Usage on July 8, 2026. The change is already partially in effect, the final cutoff is less than four weeks away, and anyone using public CA certificates for mutual TLS needs to review their setup right now.
How Chrome and Let's Encrypt Are Rewriting SSL Certificate Client Authentication
In May 2025, Let's Encrypt engineer Matthew McPherrin published a detailed announcement outlining the phased removal of SSL certificate client authentication from all Let's Encrypt certificates. The driver was a mandate from Google Chrome's root program, which imposed a June 2026 deadline for all public certificate authorities to separate TLS server authentication and client authentication into distinct, dedicated PKI hierarchies. Let's Encrypt decided to move ahead of that deadline rather than wait for it.
The rollout happened in defined stages. In October 2025, Let's Encrypt launched a new tlsclient ACME profile that retained SSL certificate client authentication EKU for users who needed more time to migrate away. On February 11, 2026, the default classic ACME profile stopped including client authentication EKU in newly issued certificates. The tlsclient profile was always a temporary measure. It expires permanently on July 8, 2026, after which no Let's Encrypt certificate will carry SSL certificate client authentication in any form – not through the classic profile, not through the tlsclient profile, and not through any new intermediate CA Let's Encrypt operates.
Why Google Chrome Triggered This Overhaul
Chrome's root program changes reflect a core security principle: a certificate authority designed for public web server authentication should not also issue credentials used to authenticate internal clients. When a single root hierarchy signs both types, a CA compromise can affect both directions of authentication simultaneously. Chrome's policy on SSL certificate client authentication closes that gap by ensuring that an attacker who compromises a web-facing certificate hierarchy cannot automatically repurpose those credentials for client impersonation attacks inside a private network.
The change also addresses a more fundamental scope problem. Public CAs issue certificates to anyone who can demonstrate control of a domain name – a model that works well for web server certificates but is unnecessarily broad when the same certificate can also authenticate an internal client. Mutual TLS for microservices, API gateways, and IoT devices is better handled by private, purpose-built certificate authorities operating within a defined trust boundary, where issuance is controlled by the organisation itself rather than a global public CA.
Apple, Mozilla, and Microsoft have aligned with similar requirements in their own root programs. Commercial CAs including DigiCert and Sectigo have already removed client authentication EKU from their publicly trusted TLS certificate hierarchies. The industry has moved in concert, and the July 8 Let's Encrypt cutoff is one of the final milestones in a coordinated, multi-year transition that has been building since Google first signalled its intentions in 2024.
What Already Changed and When the Final Cutoff Hits
For most Let's Encrypt users, the default behavior of SSL certificate client authentication changed on February 11, 2026 – and most of them never noticed, because most of them never used it. New certificates issued through the standard ACME process no longer include the client authentication EKU. Certificates issued before that date continue to function normally until they expire. Since Let's Encrypt certificates carry a 90-day validity period and auto-renew automatically, the majority of pre-February certificates have already cycled through at least one renewal without the EKU by now.
What remains is the tlsclient profile grace period. In a March 2026 update, Let's Encrypt confirmed that the final deadline had been pushed back slightly from an earlier June target to July 8, 2026, due to timeline adjustments in the root program requirements. After July 8, the tlsclient profile is permanently discontinued and Let's Encrypt will switch to issuing from new intermediate CAs that also exclude the SSL certificate client authentication EKU. There is no further extension or alternative path within Let's Encrypt to obtain client authentication certificates after that date.
Who Actually Needs to Act Before July 8
Standard Website Operators Are Largely Unaffected
The most important takeaway for the majority of website owners is that this change does not affect them at all. Standard TLS certificates – the kind that secure a website, protect visitor data, and display the padlock in the browser address bar – use only server authentication EKU. If you run a WordPress blog, an e-commerce store, or any public-facing website, your SSL certificate client authentication setup almost certainly never included the client EKU to begin with. Nothing in your environment changes on July 8, and no action is required on your part.
Applications Using Mutual TLS Face the Real Deadline
The affected use case is mutual TLS (mTLS), where both parties in a connection present certificates to authenticate each other. This pattern is common in microservices architectures, API gateways, service meshes, IoT device provisioning, and internal enterprise systems where machines verify each other rather than just a server verifying itself to a browser. If any of your services present a Let's Encrypt certificate as a client credential, rather than purely as a server certificate, the SSL certificate client authentication cutoff on July 8 is a hard stop. After that date, Let's Encrypt cannot issue a replacement carrying client auth EKU – the capability will not exist at the CA level in any form.
Moving SSL Certificate Client Authentication Workloads to Private CAs
The recommended migration path is to move all SSL certificate client authentication workloads to a private certificate authority. Tools like Smallstep Certificate Manager, HashiCorp Vault's PKI secrets engine, and managed private CA services from AWS (AWS Private CA) and Google Cloud (Certificate Authority Service) are designed exactly for this use case. Private CAs issue certificates that are not publicly trusted by web browsers, but that distinction is irrelevant for internal mTLS – each participating service trusts only the organisation's private root CA, not the public internet's trust stores.
For teams that adopted Let's Encrypt partly because it is free, the migration introduces a cost dimension that did not exist before. Cloud-hosted private CAs charge per certificate issued or per month. Open-source options like Smallstep can be self-hosted at no licensing cost, though they require operational overhead to run and maintain. The transition is a one-time migration effort rather than a recurring cost increase, and it is also an opportunity to implement tighter certificate controls – shorter validity periods, more granular issuance policies, and cleaner revocation processes than were possible using a public CA never designed for internal use cases.
Reading the Broader Signal on Certificate Policy
This change does not stand alone. The same Chrome root program requirements that drove the end of SSL certificate client authentication from public CAs are directly connected to the ongoing push to reduce TLS certificate validity to 47 days – a proposal moving through the CA/Browser Forum that would force significantly shorter lifetimes across the entire industry. According to W3Techs, Let's Encrypt holds over 57 percent of the SSL certificate market. Policy changes at that scale have outsized reach, even when the directly impacted group is a small fraction of total users.
The direction is clear and has been for some time: public certificate authorities are being pushed toward narrower, more specific roles. Server authentication for the public web is what public CAs are built for. Client authentication, internal service identity, and device provisioning belong in private PKI infrastructure. This structural separation has been years in development, and the July 8 deadline is one of the more consequential milestones in a longer arc that will keep reshaping how certificates are issued, scoped, and rotated across the industry.
Auditing Your SSL Certificate Client Authentication Setup Before July 8
The practical first step is to determine whether any of your systems actually use SSL certificate client authentication from Let's Encrypt. For most hosting customers – those on shared, WordPress, reseller, or semi-dedicated plans – the answer is no and no action is needed. For developers and infrastructure teams, start by checking ACME client configurations and certificate request logs for any use of the tlsclient profile. Review internal services, API clients, and device provisioning pipelines that rely on certificate-based mutual authentication rather than token or API key-based auth.
If you identify systems relying on SSL certificate client authentication from Let's Encrypt, begin migrating to a private CA now. July 8 leaves little margin for delay – setting up a private CA, reissuing client certificates, and updating trust stores across affected services can take days to weeks depending on the scope of your environment. For hosting customers focused on keeping their public sites fast and secure, reviewing your SSL certificate setup and confirming that auto-renewal is working correctly is always a worthwhile exercise, even if this particular change does not touch your deployment directly.
The Bottom Line
Let's Encrypt's removal of SSL certificate client authentication is a deliberate, standards-driven change backed by the combined root program requirements of Chrome, Apple, Mozilla, and the CA/Browser Forum. For most website operators, there is nothing to do. For teams running mutual TLS with Let's Encrypt certificates on the client side, July 8, 2026 is a hard migration deadline. The change reflects a clear and durable industry consensus that public and private certificate use cases require clean separation – and that consensus has the weight of the world's leading browser vendors fully behind it.
Certificate policy will keep evolving in the months ahead. Shorter validity periods, stricter transparency requirements, and new automation standards for certificate management are all in active development across the CA/Browser Forum. If you are reviewing your hosting or security infrastructure, reading about recent SSL certificate validity changes alongside this update gives a fuller picture of where the industry is heading. Staying aligned with current CA requirements is part of running a reliable, secure web operation – and MonsterMegs keeps all hosted sites covered with free, auto-renewing SSL certificates backed by modern certificate management practices.
Top comments (0)