Google Chrome Root Store Policy version 1.6, published on February 15, 2025, introduced sweeping changes that affect every public Certificate Authority trusted by Chrome and, by extension, every website relying on their certificates. The policy phases out multi-purpose root CA certificates, mandates automation support for all new applicant PKI hierarchies, and sets firm deadlines that begin as early as June 15, 2025. If your site’s SSL certificate comes from a publicly trusted CA, the decisions that CA makes in response to this policy will directly determine whether Chrome continues to trust your certificate.
What Is the Chrome Root Store Policy?
The Chrome Root Store Policy defines the minimum requirements a Certificate Authority must meet to have its root certificate included in Chrome’s trusted list. Chrome uses this list – known as the Root Store – to verify the authenticity of HTTPS certificates presented by websites. When a CA fails to meet these requirements, Google can restrict or remove that CA’s certificates, causing Chrome to display security warnings on every site the CA has issued certificates to.
Version 1.6 represents the most significant structural overhaul since the Chrome Root Program launched in 2022. It doesn’t just adjust existing rules – it redefines the type of PKI architecture Google will accept going forward.
What Changed in Version 1.6?
Version 1.6 introduced four major categories of change compared to its predecessor.
- Phase-out of multi-purpose root CA certificates. The policy established a future removal of all root CA certificates not exclusively dedicated to TLS server authentication. CAs that issue both TLS certificates and other certificate types – such as email signing or code signing – from the same root hierarchy must migrate to a dedicated TLS-only structure. Google expects this phase-out to complete by the end of 2027.
- Mandatory automation support for new applicants. Any CA applying for inclusion in the Chrome Root Store must now support at least one automated certificate issuance and renewal solution – such as ACME – for every certificate policy OID it issues under. Non-automated issuance methods are no longer acceptable for new applicants.
- Client authentication EKU deprecation. Starting June 15, 2026, all newly issued public SSL/TLS certificates must include only the serverAuth Extended Key Usage (EKU). Certificates that also carry the clientAuth EKU – meaning they can authenticate both servers and connecting users – will no longer be trusted by Chrome.
- Alignment with CA/Browser Forum Baseline Requirements. The policy updated several provisions to align with Ballot SC-077 from the CA/Browser Forum, improving consistency between Chrome’s program-specific rules and the industry-wide baseline standards.
Who Does This Policy Actually Affect?
The Chrome Root Store Policy applies directly to Certificate Authorities with root certificates included in Chrome’s trusted list. But the downstream effects reach website owners too – and that’s the part most articles miss.
As a website owner, you don’t deal with the Chrome Root Store directly. However, if your CA restructures its PKI hierarchy in response to version 1.6, your existing certificate may chain to a new intermediate CA. That change is usually transparent, but it’s worth monitoring your CA’s communication channels for migration notices. If a new intermediate CA is introduced before your renewal date, your server configuration may need to be updated to serve the correct certificate chain.
The more immediate concern for website owners is the clientAuth EKU change. If you currently use a single public SSL/TLS certificate for both server authentication and mutual TLS (client authentication), that workflow breaks on June 15, 2026. Organizations running mTLS for API security, zero-trust architectures, or financial transaction validation need to plan a migration to separate client authentication certificates – ideally ones issued by a private CA hierarchy, which is exempt from this policy.
Understanding the difference between DV, OV, and EV certificate types matters here, because each validation level carries its own CA/B Forum OID. Any CA applying for Chrome inclusion must support automation across every OID it intends to issue.
What Are the Key Deadlines?
The timeline in version 1.6 is specific, and missing any of these dates has real consequences.
| Deadline | Requirement | Who Is Affected |
| June 15, 2025 | Chrome stops accepting new Root Inclusion Requests from hierarchies using mixed EKUs (clientAuth + serverAuth intermediates) | New CA applicants |
| September 15, 2025 | Existing CAs without dedicated TLS hierarchies should begin migration | All Chrome Root Store CAs |
| June 15, 2026 | All newly issued public SSL/TLS certificates must use serverAuth EKU only | Website owners using mTLS; all CAs |
| End of 2027 | Phase-out of multi-purpose root CA certificates completes | All multi-purpose CAs in Chrome Root Store |
The June 15, 2026 deadline is the one most website owners need to mark. Certificates issued before that date remain valid until they expire, even if they carry the clientAuth EKU. But any certificate renewed or newly issued on or after that date must comply with the serverAuth-only rule.
How Do CAs Need to Respond?
For Certificate Authorities, version 1.6 sets out a demanding roadmap. CAs currently included in the Chrome Root Store that operate multi-purpose hierarchies must submit a migration plan and begin transitioning to dedicated TLS-only structures. CAs that want to remain trusted must demonstrate active progress, not just stated intentions – a lesson reinforced by Google’s 2024 decision to remove Entrust from the Chrome Root Store after years of documented compliance failures.
New applicants face the toughest requirements. They must operate dedicated TLS-only hierarchies from the start, support automated issuance (ACME or equivalent), and submit proper documentation through the Common CA Database (CCADB). The policy also restricts new applicants to CCADB Root Inclusion Requests only – no fast-track exceptions.
For subordinate CAs and externally operated CA hierarchies, version 1.6 maintains the rule that the parent CA Owner takes full responsibility for compliance at every level of the chain. An intermediate CA operated by a third-party organization does not get separate treatment – the root CA Owner that issued that intermediate is accountable for its behavior.
What Does “Dedicated TLS Hierarchy” Mean for Certificates?
A dedicated TLS PKI hierarchy is one designed solely to issue TLS server authentication certificates. It doesn’t cross over into email (S/MIME), code signing, or client authentication use cases. This matters because certificates issued by dedicated hierarchies are subject only to TLS-specific rules – not the broader, sometimes conflicting requirements that apply when a single root serves multiple purposes.
For website operators, a certificate issued from a dedicated hierarchy behaves identically to what you’re used to. The change is structural, happening inside the CA’s infrastructure. Your site still gets an X.509 certificate with a Subject Alternative Name covering your domain, a validity period of up to 398 days, and a trust chain leading to a Chrome-trusted root.
The practical benefit is improved security posture. When Google phases out multi-purpose roots, it reduces the attack surface Chrome transitively trusts. According to Google’s Chrome Root Program blog (February 2025), Chrome currently transitively trusts over 2,300 CA certificates, but only about half of those actually issue TLS certificates – meaning roughly half exist as unnecessary risk in the chain.
What Should Website Owners Do Right Now?
Website owners don’t need to take urgent action today, but three steps are worth completing before the June 2026 deadline.
- Confirm whether your current SSL/TLS certificate includes the clientAuth EKU by checking the certificate details in your browser or using a free certificate inspection tool. If clientAuth is present and you rely on it for mutual TLS, start planning an alternative setup now.
- Contact your CA and ask directly whether they plan to restructure their PKI hierarchy before the June 2026 deadline. If they do, ask whether your certificate will need to be reissued or whether the chain update will happen transparently.
- If your architecture depends on mTLS for client verification, evaluate whether a private CA – which is exempt from Chrome Root Store Policy – would better serve that use case. A private CA hierarchy gives you full control over client certificates without exposure to public policy changes.
For context on how publicly trusted CAs differ from private CA options, the comparison between self-signed certificates and trusted CA certificates covers the structural tradeoffs worth understanding before making that decision.
What Happens If a CA Fails to Comply?
Google is not subtle about consequences. A CA that fails to meet Chrome Root Store Policy requirements faces certificate removal from the Root Store – meaning every website using that CA’s certificates would suddenly receive browser warnings in Chrome. Google evaluates compliance failures based on several factors: the severity and scope of the issue, the CA’s response timeline, and whether the behavior reflects a pattern or an isolated incident.
The Entrust removal in 2024 illustrated how this plays out. Google documented a six-year pattern of compliance failures before acting. But version 1.6 shortens Google’s patience window – the policy states that failure to comply with phase-out timelines “may result in an accelerated removal timeline and/or additional restrictions.”
For website owners, the risk is passive but real. Your site doesn’t have to do anything wrong to be caught in a CA’s compliance failure. That’s why monitoring your CA’s audit reports and CCADB disclosures – both publicly available – is a reasonable precaution for any site where HTTPS availability is business-critical.
Your Migration Window Is Narrowing – Act Before the Deadline
Chrome Root Store Policy v1.6 marks a clear directional shift: Google is building a web PKI ecosystem that is simpler, more automated, and purpose-built for TLS. For CAs, the phase-out of multi-purpose hierarchies and the clientAuth EKU deprecation require concrete migration plans, not future intentions. For website owners, the immediate priority is identifying whether your current certificate setup uses clientAuth and whether your CA has communicated a compliance roadmap.
The June 15, 2026 deadline for clientAuth-free certificates is the most actionable date in this policy. Check your certificate today, confirm your CA’s plans, and separate client authentication into a private CA hierarchy if your architecture requires it. The infrastructure changes are happening whether you plan for them or not – the only variable is whether you’re prepared.
Frequently Asked Questions (FAQs)
Does Chrome Root Store Policy v1.6 affect private or enterprise CAs?
No. The policy explicitly states that CAs issuing certificates exclusively to an organization’s internal resources – sometimes called enterprise or locally trusted CAs – are not subject to Chrome Root Store Policy requirements. If your internal intranet uses a private CA, those certificates are managed entirely by your organization’s trust settings, not by Google’s root program.
What happens to existing SSL certificates that include the clientAuth EKU after June 15, 2026?
Certificates issued before June 15, 2026 remain valid until they expire, provided the issuing CA remains trusted. The new rule applies only to certificates issued on or after that date. When your certificate comes up for renewal post-June 2026, the renewed certificate must carry the serverAuth EKU only.
Do I need to do anything differently when renewing my SSL certificate after version 1.6?
In most cases, renewal is handled by your CA and should require no changes on your side unless you currently rely on the clientAuth EKU in a public certificate. If you use ACME automation through tools like Certbot or a hosting provider’s auto-renewal, the process is unchanged. If you renew manually and use mTLS, you’ll need to transition client certificates to a separate private CA setup before renewal.
How does version 1.6 relate to the 90-day certificate validity proposal?
They are separate initiatives. The 90-day maximum validity proposal – discussed within the CA/Browser Forum as ballot SC-063 – is a future change being championed by Google but not yet enacted. Version 1.6 does not change maximum certificate validity, which remains at 398 days under current CA/B Forum Baseline Requirements. However, both initiatives reflect the same broader direction: shorter certificate lifetimes and more automation.
What is the CCADB and why does version 1.6 reference it?
The Common CA Database (CCADB) is a shared data repository operated by Mozilla and used by browser vendors including Google, Apple, and Microsoft to track CA audit reports, certificate disclosures, and compliance history. Version 1.6 requires all Chrome Root Program Participants to adhere to the latest CCADB Policy and maintain up-to-date records there. It serves as the primary public transparency mechanism for CA accountability.
Can a CA be re-added to the Chrome Root Store after removal?
Yes, but the path back is demanding. Google’s statement on the Entrust removal noted that a removed CA can “regain the trust required to serve as a public CA in the future” through demonstrated, sustained improvement. In practice, that means completing a new inclusion application, satisfying all current policy requirements, and maintaining transparent audit records – a process measured in years, not months.
Priya Mervana
Verified Web Security Experts
Priya Mervana is working at SSLInsights.com as a web security expert with over 10 years of experience writing about encryption, SSL certificates, and online privacy. She aims to make complex security topics easily understandable for everyday internet users.
