Chrome Root Program Policy v1.6: What CAs Must Know

Chrome Root Program Policy v1.6: What It Means for Your Certificates

A policy update from Google Chrome is quietly rewriting the rules of public certificate trust — and the deadline is June 2026. If your organisation relies on public certificate authorities for TLS client authentication, the Chrome Root Program Policy v1.6 demands immediate attention.

The change is specific: Chrome will no longer trust public SSL/TLS certificates that carry the clientAuth Extended Key Usage (EKU). From 15 June 2026, any such certificate issued by a public CA will be distrusted by Chrome — regardless of when it was issued after that date.

What the Chrome Root Program Policy v1.6 Actually Changes

Published in February 2025, Chrome Root Program Policy v1.6 mandates that all certificate hierarchies included in Chrome’s Root Store must be dedicated solely to TLS server authentication. In plain terms: public CAs can no longer issue certificates that serve double duty — both server authentication and client authentication.

The technical driver is the Extended Key Usage extension. Certificates issued by public CAs historically included both id-kp-serverAuth and id-kp-clientAuth in the EKU field, enabling organisations to use a single certificate hierarchy for multiple purposes. That flexibility ends with v1.6.

Key dates to note:

• Before 15 June 2025: Sub-CA certificates in the Chrome Root Store may include both serverAuth and clientAuth EKUs.

• 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.

Certificates already issued before the June 2026 cutoff remain valid until their natural expiry — but no new ones will be accepted.

Who Is Affected and Why It Matters

TLS client authentication verifies the identity of the client — a device, user, or workload — when it connects to a server. It is distinct from server authentication, which validates the server to the browser. Many enterprises have relied on public CAs for client auth scenarios without fully realising it, because it was convenient and cost-effective.

Affected use cases include:

• VPN access — authenticating employee devices connecting remotely.

• Wi-Fi onboarding — certificate-based device authentication replacing static passwords.

• Mutual TLS (mTLS) — securing API communication in microservices and DevOps pipelines.

• Single Sign-On (SSO) — certificates embedded in endpoint devices for identity.

• Machine identity management — authenticating workloads and containers.

The broader driver behind v1.6 is a deliberate industry shift toward dedicated PKI hierarchies. Multi-purpose certificates introduce complexity and potential for misconfiguration. By separating server and client authentication, Google is strengthening the integrity of public PKI — and aligning with CA/Browser Forum Ballot SC-077 in the process.

The Migration Path: Private CA Capabilities and Certificate Lifecycle Management

For organisations using public certificates for client authentication, the only sustainable path forward is a private certificate authority infrastructure. Unlike public CAs — which are bound by browser policies, external audits, and compliance mandates — a privately operated CA gives organisations full control over certificate profiles, issuance policies, and revocation, without dependency on the Chrome Root Store.

Private CA infrastructure supports the protocols enterprises need: ACME for automation, EST and SCEP for device enrolment, and custom policy enforcement on key length, validity periods, and permitted EKUs.

Migration alone is not enough, however. As certificate lifespans shorten — CA/Browser Forum has already voted to reduce maximum TLS certificate validity to 47 days — manual tracking becomes unsustainable. Certificate Lifecycle Management (CLM) is now essential infrastructure, providing automated discovery, renewal, revocation, and policy enforcement across the entire certificate estate.

eMudhra’s CertiNext combines a full-featured, WebTrust-audited certificate authority suite with automated lifecycle management in a single platform — covering certificate issuance, dedicated TLS hierarchies, renewal, revocation, and discovery across both public and private trust environments. Organisations looking to migrate away from multi-purpose public CA certificates will find everything they need in one solution.

What Organisations Should Do Before June 2026

The June 2026 enforcement date is fixed. The steps below provide a practical starting point:

• Audit certificate usage: Identify every certificate in your environment that includes the clientAuth EKU. Determine which services, devices, or pipelines depend on them.

• Assess risk and prioritise: Map affected certificates to business-critical services. Plan replacements around expiry dates and operational risk.

• Deploy a dedicated CA hierarchy: Select a solution that supports automation and integrates with your existing tooling. CertiNext provides a purpose-built CA suite with ACME, EST, and SCEP support for enterprise PKI deployments.

• Automate certificate lifecycle management: CertiNext unifies discovery, automated renewal, policy enforcement, and revocation across your full certificate estate — eliminating manual tracking as lifespans continue to shrink.

• Align teams and get expert support: Ensure IT, DevOps, and security operations understand the scope and timeline. Contact eMudhra to assess your current certificate posture and build a migration plan ahead of the deadline.

Chrome’s move to server-auth-only public PKI is not a temporary measure. It reflects the direction the broader industry is heading — toward tighter trust boundaries, greater automation, and dedicated certificate hierarchies for each authentication purpose.

Is Your Certificate Infrastructure Chrome-Ready?

eMudhra’s CertiNext brings together a full certificate authority suite and automated lifecycle management in one platform — giving enterprises everything they need to migrate to a dedicated TLS hierarchy and stay ahead of Chrome’s June 2026 enforcement deadline.

Talk to an expert today: Contact eMudhra.