Notifications
Clear all
Topic starter
24/06/2026 7:07 pm
TL;DR: Browsers led by Google are ending support for dual-EKU public TLS certificates, which will remove ClientAuth from browser-trusted roots and force organisations to redesign mTLS and other client-authentication patterns, according to DigiCert. The shift exposes how much enterprise trust infrastructure depended on certificates doing two jobs at once.
NHIMG editorial — based on content published by DigiCert: What the End of Dual-EKU TLS Means for ClientAuth and mTLS
Questions worth separating out
Q: What breaks when public TLS certificates stop supporting client authentication?
A: Applications that depended on dual-purpose public certificates will lose a simple path for mTLS and client authentication.
Q: When should organisations use private PKI instead of public certificates for client auth?
A: Private PKI is usually the better fit when client authentication is limited to internal systems, administrative access, or services that do not need browser trust.
Q: How do security teams know whether mTLS needs a redesign?
A: If mTLS depends on certificates that were issued for both server and client use, the design needs review.
Practitioner guidance
- Inventory dual-EKU dependencies Identify every application, service, and partner flow that still relies on a public certificate carrying both serverAuth and clientAuth.
- Separate client authentication from server TLS policy Create distinct certificate profiles for server authentication and client authentication, and stop treating one certificate template as a universal trust object.
- Choose private PKI for internal-only identities Move internal services and administrative interfaces that never cross the internet to private PKI where you control subject naming, issuance rules, and lifetime.
What's in the full article
DigiCert's full blog covers the operational detail this post intentionally leaves for the source:
- Browser-root policy context for why dual-EKU certificates are being phased out
- How DigiCert X9 PKI is positioned for client authentication outside the Web PKI
- Operational reasons internal PKI can be the better fit for internal-only services
- Planning considerations for organisations that need certificate agility, including PQC readiness
👉 Read DigiCert's analysis of the end of dual-EKU TLS for clientAuth and mTLS →
Dual-EKU TLS deprecation: what it means for client auth and mTLS?
Explore further
25/06/2026 4:15 am
Dual-EKU retirement is a certificate-purpose governance failure, not just a browser policy change. The old model assumed one public certificate could legitimately carry both server and client trust semantics. That assumption was convenient for operations, but it was always fragile because it blurred identity purpose inside the certificate itself. The implication is that certificate programmes now need to be designed around purpose separation, not reuse.
A few things that frame the scale:
- 66% say their current tooling is not adequate to manage the scale of machine identities they now have, according to The Critical Gaps in Machine Identity Management report.
- 59% of companies face greater difficulties auditing machine identities, primarily due to lack of clear ownership and limited visibility.
A question worth separating out:
Q: What is the difference between public PKI and private PKI for workload identity?
A: Public PKI is designed for broadly trusted identities that need external validation, while private PKI is controlled by the organisation and better suited to internal workload and client identities. The difference is governance, not just technology. Public trust reduces distribution effort, but private trust gives tighter control over lifecycle and exposure.
👉 Read our full editorial: Dual-EKU TLS deprecation is forcing clientauth certificate redesign
