Understanding Chrome Root Program at a Glance
Ever used the same key for your house, office, car, and that one super-secure locker? It’s convenient until you lose it – then every lock is at risk. That’s exactly what multi-use certificates do in digital security. One compromised cert can expose multiple functions. Chrome is trying to fix this with its recent overhaul of how digital certificates are trusted.
Google’s Chrome Root Program is undergoing a serious architectural update. The idea is to tighten control over the trust chain, reduce complexity in certificate roles, and push the web toward a more purpose-specific PKI (Public Key Infrastructure).
This shift is about more than compliance; it’s about rethinking how trust is managed on the internet. By setting stricter boundaries and expectations around certificate usage, Chrome is leading the charge toward a “purpose-built” PKI where certificates only do what they’re supposed to do, nothing more, nothing less.
In this breakdown article, we’ll explore what’s changing, why it matters, how Certificate Authorities are reacting, and what developers, sysadmins, and security teams need to start prepping for right now.
The Chrome Root Program: A Foundation of Trust
At the core of Chrome’s security model is the Chrome Root Program Policy, a strict framework outlining what CAs must follow to have their root certificates trusted in Chrome’s Root Store. This includes strong controls around key management, certificate transparency, incident reporting, and auditable compliance.
With Version 1.1, Google launched the “Moving Forward, Together” initiative, a push toward a more modern, purpose-bound PKI. It accentuates continuous auditing, tighter certificate lifecycle controls, and swift cancellation of CAs that don’t meet the bar. The message is clear: trust is earned, monitored, and revocable.
Core Shift 1: Chrome Tightens TLS Trust Model (Client Authentication Gets the Boot)
One of the most impactful shifts in the Chrome Root Program is the deprecation of clientAuth in publicly trusted SSL/TLS certificates. This move stems from the policy’s focus on Dedicated TLS Server Authentication PKI Hierarchies. In simple terms: every certificate should serve a single, clearly defined purpose. No more all-in-one certs.
What’s Actually Changing?
Intermediate Certificates:
Starting June 15, 2025, public CAs will no longer be allowed to issue intermediate certificates that include both serverAuth and clientAuth EKUs. This upstream restriction enforces clean separation of roles, particularly impacting mTLS and dual-use hierarchies.
Leaf Certificates:
By June 15, 2026, Chrome will stop trusting newly issued leaf certificates that contain both serverAuth and clientAuth EKUs. This marks a full commitment to single-purpose certificate usage in the trust chain.
Quick Overview
-
EKU (Extended Key Usage): An essential X.509 certificate extension that defines what a certificate is allowed to do. For example, id-kp-serverAuth is used for authenticating web servers (HTTPS), while id-kp-clientAuth is used for authenticating clients in secure connections.
- Client Authentication: Primarily used in Mutual TLS (mTLS), where both client and server present certificates to verify each other’s identities. Common in enterprise environments, IoT communications, and internal service-to-service authentication.
But Why Is Chrome Making This Change?
The move to split clientAuth and serverAuth in public certificates is rooted in both security and operational clarity:
- Overloaded Certificates Increase Risk:
Bundling clientAuth and serverAuth is like handing out a master key. If compromised, it can impact both server validation and client authentication, doubling the attack surface. - Clear Public vs Private Boundaries:
clientAuth is typically used in internal systems, corporate VPNs, IoT networks, and mTLS setups, where private CAs are better suited. Chrome’s policy encourages keeping serverAuth for public-facing sites and pushing clientAuth into private PKI realms. - Easier Auditing and Policy Enforcement:
Purpose-bound certificates simplify compliance, monitoring, and incident response. When roles are separated, it’s easier for CAs, browsers, and organizations to track usage and avoid misconfigurations.
As Google puts it: “The goal is to improve the ecosystem by encouraging separation of usage.”
While Chrome is streamlining certificate purposes to reduce misuse risks, it’s also doubling down on who issues these certificates. After all, a secure certificate means little if the issuing Certificate Authority itself can’t be trusted. This brings us to Chrome’s next major move.
Core Shift 2: Proactive CA Distrust and the SCTNotAfter Mechanism
Beyond clientAuth deprecation, the Chrome Root Program is taking a much more aggressive stance on CA compliance and accountability. This is where the “Upcoming Changes to the Chrome Root Store” truly comes into play, signifying a deeper curation of trusted CAs
Recent Distrust Actions: Chunghwa Telecom & NetLock
On May 30, 2025, Google announced it would remove default trust for new TLS certificates issued by Chunghwa Telecom (Taiwan) and NetLock (Hungary). Starting with Chrome 139 rolling out around August 1, 2025, Chrome will stop trusting certificates issued by these CAs after July 31, 2025, 23:59:59 UTC.
Why the Distrust?
Google’s decision wasn’t arbitrary; it was based on repeated patterns of concern, including:
- Ongoing compliance failures,
- Unfulfilled remediation commitments and
- Lack of measurable progress following public security incidents.
Given the critical trust placed in public CAs, Google determined that continued inclusion in the Chrome Root Store was no longer justified. This move is a proactive safeguard to protect users and uphold the integrity of the web’s trust model.
The SCTNotAfter Distrust Mechanism: A Smarter Approach
Unlike older, disruptive distrusts (think Symantec), Google is using a more refined method: SCTNotAfter. This allows Chrome to distrust CAs like Chunghwa Telecom and NetLock without breaking existing sites overnight.
What’s an SCT?
Signed Certificate Timestamps (SCTs) are cryptographic proofs that a certificate was logged in a Certificate Transparency (CT) log a public, auditable system that helps detect CA misbehaviour.
How SCTNotAfter Works:
Chrome sets an SCTNotAfter cutoff e.g., August 1, 2025. Any certificate from the distrusted CA must include at least one SCT dated before that cutoff. Certificates issued after that date fail validation, regardless of their actual issuance date.
This means that older, still-valid certificates continue to work until they expire naturally, while new certificates are instantly blocked, without triggering widespread “connection not private” errors.
It’s a clean, forward-looking distrust model that enforces security policy with minimal user disruption.
What You Need to Know & What to Do
These changes, particularly the deprecation of clientAuth, warrant a thorough review of your PKI architecture, especially if your organization uses public certificates for client-side authentication.
Running a standard website?
If your site uses SSL/TLS certificates solely for serverAuth (i.e., HTTPS for encryption and identity), you’re largely unaffected, as long as your certificates are issued by a compliant public CA. That said, it’s still important to stay informed about ongoing Root Store changes that may impact CA trust status.
Using Mutual TLS (mTLS) or Client Authentication?
If your systems rely on publicly trusted certificates for client-side use cases, immediate action is recommended. Common scenarios include:
- Corporate VPNs or internal apps using client certificates for user/device authentication
- IoT deployments where a single certificate is used for both serverAuth and clientAuth
- Service-to-service communication within distributed systems backed by public CAs
In these cases, you should begin planning a migration to private CAs or request dedicated TLS client certificates, as multi-use public certs will no longer be supported.
Best Practices for Adaptation
Public-Facing Websites | Continue using serverAuth certificates from trusted public CAs (e.g., DigiCert, Sectigo, etc.). Ensure your CA complies with Chrome’s updated Root Policy. |
Client Authentication / mTLS | Migrate to a private CA or use dedicated tlsclient certificates. For internal apps, IoT, or enterprise mTLS, private PKI offers more control and aligns with best practices. Some public CAs provide tlsclient certs via API for niche needs. |
Certificates from Distrusted CAs | Replace any certs issued by Chunghwa Telecom or NetLock. Certificates issued after July 31, 2025, will trigger Chrome warnings. Replace existing certs proactively. |
Certificate Authority Actions
Major CAs have already begun aligning with Chrome’s updated policies:
CA | Action Plan | Key Dates |
---|---|---|
DigiCert | Defaulting to serverAuth only; full elimination of clientAuth in public certs. | Oct 1, 2025 (default), May 1, 2026 (full) |
Sectigo | Phase-out of clientAuth from public certificates begins. | Sept 15, 2025 → ends May 15, 2026 |
Other CAs (generalized) | Many leading CAs are now shifting to dedicated hierarchies for serverAuth and clientAuth. Expect public TLS certificates to default to single-use profiles or issue clientAuth-only certs via API or private hierarchies. | By mid-2026, most public CAs will fully transition. |
If you’re requesting a new SSL certificate post-2025 from a public CA, clientAuth will likely be automatically stripped from it or it will be issued from a dedicated serverAuth hierarchy.
TL;DR Checklist for Action
Task | Recommendation |
---|---|
Audit Existing Certificates | Use openssl or certificate linter tools, and Chrome’s Developer Tools, to identify any publicly trusted certificates that include clientAuth. |
Plan Migration for mTLS/ClientAuth | If you rely on public certificates for client authentication, design a strategy to transition to a private CA or dedicated tlsclient certificates. |
Separate PKI Hierarchies | Actively work to separate your public-facing serverAuth needs from your internal clientAuth requirements. |
Review CA Timelines | Mark key transition dates provided by your CA in your calendar to anticipate changes. |
Update Internal Policies | Adjust your procurement and issuance policies to stop requesting multi-purpose public certificates after 2025. |
Replace Distrusted Certificates | If using Chunghwa Telecom or NetLock, prioritize replacing those certificates from a new, trusted public CA before August 1, 2025. |
Test in Staging Environments | Simulate certificate chain changes and potential distrusts in a staging environment before full rollout to production. |
Stay Informed on Chrome Root Program | Regularly check the Chrome Root Program Policy and Google Security Blog for ongoing updates to trusted CAs and policy changes. |
Broader Trends and Future Outlook
The deprecation of clientAuth and Chrome’s proactive CA distrust measures reflect a wider evolution in the web PKI landscape. Key developments to watch:
- Shorter Certificate Lifetimes
The validity period for public TLS certificates is trending downward—from today’s 13-month maximum toward 47-day cycles, per CA/B Forum’s plan through 2029—to limit key-compromise windows and drive automated renewal workflows. - Expanded Certificate Transparency Logging
Stronger CT requirements are being adopted industry-wide, increasing public visibility into certificate issuance and making mis-issuances far more difficult to hide. - Tighter CA Compliance and Audits
Browsers now demand rigorous operational security, incident-response processes, and continuous compliance from CAs, with swift distrust actions for repeat failures. - Automation and Purpose-Built PKI
The emphasis is shifting from catch-all, multi-purpose certificates toward highly automated, narrowly scoped PKI, where each certificate has a single, well-defined role and lifecycle.
Conclusion
All these trends reinforce Chrome’s mission: creating a safer, more transparent internet with certificates that do exactly what they’re meant to. This isn’t just about retiring old practices; it’s about forging a more secure, transparent, and manageable certificate ecosystem. For developers, sysadmins, and DevSecOps teams, now is the time to:
- Audit your current certificate inventory,
- Plan migrations to purpose-built PKIs or private CAs, and
- Automate certificate issuance and renewal.
By 2026, generic, multi-use certificates will be obsolete. Adopting specialized, automated PKI architectures today will future-proof your infrastructure and maintain user trust.