Topic starter
12/07/2026 12:18 pm
TL;DR: Chrome Root Program Policy v1.6 will distrust public TLS certificates carrying clientAuth EKU from 15 June 2026, forcing organisations that use public CAs for client authentication, mTLS, VPN, Wi-Fi and workload identity to move to dedicated hierarchies, according to eMudhra. The policy turns certificate lifecycle and trust-boundary management into an immediate machine identity governance issue rather than a routine PKI preference.
Editorial analysis by NHI Mgmt Group, based on content published by eMudhra: “Chrome Root Program Policy v1.6: What CAs Must Know”.
By the numbers:
- From 15 June 2025, new subordinate CA certificates must include only serverAuth EKU.
- From 15 June 2026, Chrome distrusts any public TLS certificate containing the clientAuth EKU.
- CA/Browser Forum has already voted to reduce maximum TLS certificate validity to 47 days.
Key questions
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: Why does Chrome’s client-auth policy change matter for PKI and IAM teams?
A: It forces certificate governance to distinguish between server identity and client identity, which means issuer choice, profile design, and lifecycle ownership now affect access continuity.
Q: How should organisations migrate away from public CAs for client-auth certificates?
A: They should move client authentication to a dedicated private CA hierarchy, map every affected certificate to its dependent service, and reissue before expiry rather than waiting for the Chrome cutoff.
Practitioner guidance
- Inventory all client-auth certificates Identify every certificate that contains clientAuth EKU and map each one to the service, device, workload, or user flow that depends on it.
- Split server and client hierarchies Design a dedicated TLS hierarchy for server authentication and move client authentication to a separate private CA path with purpose-specific profiles.
- Prioritise business-critical replacements Rank certificates by expiry date and operational dependency so the highest-risk client-auth paths are reissued first.
Bottom line: Chrome’s client-auth cutoff turns a browser policy into a machine identity governance problem for any organisation that still uses public CAs for authentication.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
12/07/2026 12:31 pm
Dedicated hierarchy design is becoming a machine identity governance requirement: Chrome’s policy makes it clear that certificate purpose can no longer be treated as an administrative preference. Public trust stores are enforcing a narrower separation between server identity and client identity, which pushes certificate governance into a more explicit machine identity model. The practitioner implication is straightforward: the certificate hierarchy itself now has to reflect the identity function being performed.
A question worth separating out:
Q: How should teams prioritise certificate lifecycle management over manual administration?
A: Teams should prioritise lifecycle management when certificate populations are too large for spreadsheets and ad hoc reminders. Central discovery, ownership and renewal workflows reduce the chance that critical certificates expire unnoticed across business units and hybrid environments.
👉 Read our full editorial: Chrome Root Program v1.6 forces dedicated client-auth certificate hierarchies