For most of Chrome’s life — and for Internet Explorer and Safari before it — the question “does my browser trust this certificate?” had a boring answer: it trusts whatever the operating system trusts. Chrome on Windows asked the Windows certificate store. Chrome on a Mac asked Keychain. The browser was a tenant; the OS was the landlord that decided which certificate authorities got to vouch for the web, and Chrome just lived there. This was so ordinary that almost nobody thought of it as a decision. It was simply how trust worked.
Then, in September 2022, Chrome stopped asking.
Chrome 105 shipped something called the Chrome Root Store: a list of trusted certificate authorities that Chrome carries with it and updates on its own schedule, independent of the machine it’s running on. It rolled out platform by platform — Windows and macOS first (on by default from Chrome 108), then ChromeOS and Linux in Chrome 114 and Android by Chrome 115 — and if you never read the release notes you’d never have noticed. (Chrome still honors roots that you or your IT department install locally; what it stopped deferring to is the OS vendor’s public list.) Every site that loaded yesterday loaded today. The entire point of the change was that nothing visible happened.
What the change actually did was move a decision, and it took two more years for most of us to see what that meant.
The Job That Moved
The old arrangement wasn’t just convenient, it was invisible governance. When Chrome trusted the OS root store, the people deciding which CAs could issue certificates for the entire web were, functionally, Microsoft’s and Apple’s root program teams. Their lists weren’t identical, browsers papered over the differences, and the whole thing mostly held together because the big CAs all wanted to be in every store at once.
The Chrome Root Program changes who holds the pen. Chrome now ships its own list of roots, decided by its own team against its own written policy, and distributed to the browser the same way any other component update arrives — out of band, on Google’s cadence, not your OS vendor’s. Inclusion comes with requirements the OS stores historically didn’t enforce as strictly: certificates have to show up in Certificate Transparency logs, CAs have to run dedicated hierarchies for TLS rather than one root that signs everything, and a CA that mishandles an incident can be shown the door. The shared source of truth for all of this is the CCADB, but the trust decision — the part that actually points a browser at a padlock or a warning — is now Chrome’s to make alone.
For a long time this was theoretical. Then it wasn’t.
What It Bought: Entrust
Entrust is a certificate authority old enough to predate most of the companies reading this. It has been in the OS trust stores essentially forever. And in June 2024, the Chrome Security Team announced that Chrome would stop trusting it.
The mechanics were specific in the way these things have to be. Chrome would distrust TLS certificates chaining to Entrust roots whose earliest Signed Certificate Timestamp was dated after November 11, 2024 — meaning certificates issued after that line got no trust, while ones already in the field kept working until they expired. It landed in Chrome 131. Enforcement began on November 12, and from then on a freshly issued Entrust certificate got a full-page interstitial instead of a padlock. The stated reason wasn’t a single dramatic breach; it was, in Chrome’s words, a “pattern of compliance failures” stretching back roughly six years, enough that the team said its confidence in Entrust’s “competence, reliability, and integrity as a publicly-trusted CA Owner” had eroded. Mozilla, which has run its own root store for decades, drew a similar line at November 30. Apple drew one at November 15.
Here is the detail that makes the point. Windows did not cut Entrust off that November; Microsoft added its own cutoff months later, in a February 2025 root update, and only for certificates issued after April 16, 2025. (Apple is the exception that proves the rule: its root store is the OS, so its November 15 line applied to macOS itself.) So for that whole winter, on a Windows machine where Chrome threw a security warning, the operating system underneath it still considered the same Entrust certificate perfectly trustworthy — and any app that used the system trust store, from a scripting language’s HTTP client to a line-of-business desktop app, would happily connect. The certificate wasn’t revoked. It wasn’t expired. It failed for one reason only: the specific program you opened had its own opinion, and that opinion no longer matched the computer’s.
That state — trusted by your OS, rejected by your browser, for a live and unexpired certificate — wasn’t brand new. Chrome had produced it before by bolting hand-written exceptions onto the OS store: CNNIC in 2015, WoSign and StartCom in 2016–17, Symantec in 2018. But each of those was a special patch against someone else’s list. Now the list itself is Chrome’s, and disagreeing with the OS is the default arrangement rather than an emergency measure.
The Trade
I think Chrome was right to do this, and I don’t think it’s especially close. Tying web trust to OS trust meant CA discipline moved at the speed of Windows Update and macOS point releases, and it meant a CA could coast on the enormous inconvenience of being distrusted. A browser that ships its own store can act on a compliance problem in a release cycle instead of a decade, and it can hold a consistent bar across every platform instead of inheriting five different ones. Certificate Transparency, which is the single best thing to happen to the CA ecosystem in years, is enforceable precisely because a browser can require it as a condition of trust and mean it.
But it’s worth naming what you traded, because “nothing visible happened” hides the size of it. Trust used to be singular — one list, more or less, that everything on your machine deferred to. It’s now plural and program-specific. Chrome has its store, Mozilla has always had its own, Apple has its own, Microsoft has its own, and they no longer have to agree. “Works in Safari, broken in Chrome” is no longer necessarily a rendering bug or a cache problem; it can be a straightforward disagreement about whether a certificate authority should be trusted at all, with both browsers correct according to their own rules.
And the lever is now concentrated. Google can, on its own timeline and its own judgment, decide that a certificate authority is finished for the roughly two-thirds of web browsing that happens in Chrome, and there is no OS vendor in the loop to slow it down or overrule it. So far the judgment has been careful and the reasons have been public and specific, which is the only thing that makes concentrated power like this tolerable. The Entrust decision came with six years of documented incidents, not a press release. That’s the standard to hold them to, every single time, because the mechanism that dropped a badly-run CA in 2024 is the same mechanism that trusts the good ones, and it answers to no one but Google. The OS used to be a check on that, mostly by accident. It isn’t anymore, and it’s not coming back.