Skip to content

The Web PKI trust store: how browsers decide which CAs to trust

· 22 min read
Copyright: MIT
tls pki web-security
Wordmark reading ROOT STORE with an orange trust-anchor accent on a near-black background

When your browser opens a connection to a site over HTTPS, it has to answer one question in the first few milliseconds: is the certificate this server just handed me signed by someone I trust? The whole edifice of web security rests on the answer, and the answer comes from a list. A few hundred certificates, baked into your browser or your operating system, each one a root certificate authority your software has decided to vouch for. If a certificate chains up to one of those roots and the chain validates, the padlock appears. If it does not, you get the full-page interstitial and most users turn back.

So who put those roots on the list, and who can take one off? That decision is not made by a standards body with the force of law. It is made by a handful of organizations that ship browsers and operating systems, each running its own root program, each with its own policy document, its own public mailing list, and its own ability to delete a certificate authority from the web with a single software update. This post is about that machinery: how a CA gets into a trust store, what trust actually means in this context, the governance layer that sits above the individual root programs, and the three times in the last decade a major CA got marched back out the door.

What a trust store actually is

A root store is a set of self-signed certificates. Each one belongs to a certificate authority that the store operator has decided to trust as a starting point for chain validation. When a server presents its leaf certificate, it usually also sends one or more intermediate certificates. Your browser walks the chain from the leaf up through the intermediates until it reaches a certificate it already has in its store. If that terminal certificate is a trusted root, and every signature in the chain checks out, and none of the certificates has expired or been revoked, the connection is authenticated.

The roots themselves almost never sign end-entity certificates directly. The root’s private key is the crown jewel; it lives offline in a hardware security module and comes out for ceremonies, not for issuing your blog’s TLS cert. Instead the root signs intermediate CAs, and those issue the certificates you actually see. This is deliberate. If an intermediate is compromised it can be revoked without burning the root, and the root key can sit in a vault for its entire fifteen-to-twenty-year life almost untouched.

Chain validation leaf cert example.com intermediate CA issuing CA root CA self-signed signed by signed by trust store ~150 roots, shipped match? *The leaf is signed by an intermediate, the intermediate by a root, and the root must already be present in the browser's trust store for the chain to validate. The root key itself stays offline.*

That last clause is where the trust store earns its keep. Expiry and revocation are part of validation, and the revocation story has its own fingerprint surface worth a separate read in OCSP, OCSP stapling, and the revocation-check fingerprint. What the trust store adds on top is the membership question. A perfectly valid signature from a CA that is not in your store buys nothing. Trust here is binary at the root and entirely a matter of who curates the list.

The roadmap from here: where the stores live and who runs them, what the word “trust” actually buys you, the CA/Browser Forum and the audit regime that sits above all four root programs, the Common CA Database that ties them together, Chrome’s decision to build its own store and the program that came with it, and then the distrust events, Symantec through Entrust, that show the enforcement model working in anger. A short note on certificate lifetimes closes it out, because that is where the governance fight has moved.

Four stores, four programs

There is no single web trust store. There are several, and which one your software consults depends on the platform and the application.

Microsoft runs the Trusted Root Program, and its store ships with Windows. Apple runs its Root Certificate Program, and that store is built into macOS, iOS, and the rest of the operating systems. Mozilla maintains the root store that ships with Firefox and, because it is open and well-documented, the one that a large fraction of the Linux and server ecosystem inherits, often via the ca-certificates package that repackages Mozilla’s list. And Google, since 2022, runs the Chrome Root Program with its own store that Chrome carries on most desktop and Android platforms.

Each program publishes a policy that a CA must satisfy to get in and stay in. The shapes rhyme but differ in the specifics. Microsoft’s program requires that a new root be valid for at least eight years from submission and expire no more than twenty-five years out, that the root carry keyCertSign and cRLSign key usage only, and that the CA provide a business justification for every extended key usage assigned to the root. Apple’s program leans hard on the CA/Browser Forum Baseline Requirements, demanding constant compliance with the current version, strict adherence to the Common CA Database policy, advance notice of any change in control, and a stated cap on the number of roots per provider. Mozilla’s policy, at version 3.0 effective March 15, 2025, makes the open-governance posture explicit: decisions about which CA certificates are included are made “based on the risks of such inclusion to typical users,” and Mozilla reserves the right to “disable (partially or fully), or remove a certificate, at any time and for any reason.”

The differences matter in practice. A CA distrusted by Chrome is not automatically distrusted by Safari. Symantec’s certificates kept working in some environments after Chrome and Firefox had moved on. This is why a site operator who wants the green padlock everywhere has to satisfy the union of all four programs, and why the programs, despite their independence, have strong incentives to converge through shared infrastructure.

What “trust” buys, and what it does not

It helps to be precise about the claim a root store makes. Including a CA’s root means the store operator believes that CA validates the things it claims to validate before it signs a certificate, audits itself against an agreed standard, and will revoke and disclose when it gets something wrong. For the standard domain-validated certificate that backs almost all of HTTPS today, the thing being validated is narrow: control of a domain name at issuance time. The CA confirmed that whoever requested the certificate could answer a challenge on the domain, by serving a file, answering a DNS query, or responding on a well-known port.

That is the entire claim. A DV certificate for example.com asserts that the holder demonstrated control of example.com to a trusted CA. It says nothing about who the holder is, whether the site is honest, or whether the content is safe. A phishing site can hold a perfectly valid certificate. The padlock was never a safety rating; it is an authentication primitive that says the bytes you are receiving came from a server that controls the name in the address bar and have not been read or altered in transit by anyone between you and that server. Useful, necessary, and routinely overstated.

The trust is also transitive and broad in a way that is easy to forget. Any root in your store can issue a certificate for any domain on the internet. There is no partitioning by default; the root that a CA in one jurisdiction operates can technically sign a certificate for a bank in another. That single fact is the entire reason the governance layer exists, the reason Certificate Transparency was built, and the reason a CA that abuses or loses control of that power gets removed rather than warned. The blast radius of one compromised trusted root is the whole web. The detection layer that grew up to watch for exactly that abuse is its own topic in Certificate transparency: how CT logs work and what they reveal.

The forum and the audits above the stores

If each browser wrote its own rules for how a CA must validate a domain or size a key, CAs would face four incompatible rulebooks and the web would fragment. The CA/Browser Forum exists to stop that. It is a voluntary consortium of certificate authorities and the vendors of browsers and operating systems, and since 2011 it has published the Baseline Requirements, the common rulebook for issuing publicly-trusted TLS certificates. The Baseline Requirements define how domain control is validated, which key sizes and algorithms are acceptable, the maximum certificate lifetime, when a certificate must be revoked, and what a CA must audit itself against.

The Forum has no enforcement power of its own. It writes the rules; the root programs enforce them. A CA is audited annually against the Baseline Requirements under one of two schemes, the WebTrust Program for Certification Authorities or the ETSI standards in the EN 319 411 family, by an accredited auditor. The audit report is public. The root programs read those reports, and a CA that fails an audit, lets its audit lapse, or racks up unresolved incidents finds its place in the trust stores at risk. The Forum and the programs form a layered system: shared rules at the Forum, independent enforcement at each store, public audits as the evidence that ties the two together.

CA/Browser Forum writes the Baseline Requirements (since 2011) enforced by Mozilla Firefox + Linux Apple macOS / iOS Microsoft Windows Google Chrome (2022+) Common CA Database (CCADB) shared audit + incident data across all four programs WebTrust / ETSI audits feed the database; programs read it *The Forum sets common rules, each of the four programs enforces them independently, and the Common CA Database is the shared layer where audit and incident data lives so the programs do not have to track every CA in isolation.*

CCADB: the shared spine

Running a root program means tracking the audit status of every CA in your store, every intermediate they operate, every incident report, and every gap in coverage. Doing that four times over, once per program, would be wasteful and error-prone. The Common CA Database, created and run by Mozilla and now used and funded as a Linux Foundation project with Mozilla, Google, Microsoft, Apple, and Cisco all contributing, is the shared system that holds it.

A CA with a certificate in any participating store has to use CCADB. They file their root and intermediate certificate disclosures there, upload their annual audit statements there, and submit inclusion requests through it. The database automatically detects and alerts root store operators when a CA has an outdated audit statement or a gap between audit periods, which is exactly the kind of slow administrative failure that used to slip through. Mozilla’s writeup of the system makes the point plainly: audit statements are the assurance that a CA is following the procedures that keep it from issuing fraudulent certificates, and CCADB makes lapses visible.

Inclusion now flows through CCADB as the front door. When a CA wants into Chrome’s store, Apple’s, or Mozilla’s, it files a Root Inclusion Request in the database, and the relevant program evaluates it against its policy. The database does not make the trust decision. It is the system of record that makes the decision auditable and keeps the four programs working from the same data rather than four divergent spreadsheets.

Chrome builds its own store

For most of Chrome’s life it did not have a root store. On Windows it trusted whatever Microsoft trusted, on macOS whatever Apple trusted, and so on, deferring to the host operating system’s verifier and store. That changed in 2022. With Chrome 105, released in September 2022, Google began a platform-by-platform transition to its own Chrome Root Store and its own certificate verifier, rolling it out across Windows, macOS, ChromeOS, Linux, and Android. Chrome on iOS is the exception; Apple’s platform policies require browsers there to use the system verifier, so the Chrome Root Store does not apply on iPhones and iPads.

The motivation was consistency and control. Shipping its own store and verifier lets Chrome behave the same way across every platform it runs on, instead of inheriting five different sets of behavior from five different operating systems. It also lets Google move on its own schedule. When Chrome wants to distrust a CA or change a validation rule, it can ship that in a Chrome update rather than waiting for an OS vendor to act. The store itself lives in the Chrome binary, in a component that updates out of band, so a trust decision can reach users within days rather than tied to a full release.

That control is the whole point of the Chrome Root Program, the policy regime that came with the store. The program is unusually direct about its bar for inclusion. The version 1.8 policy, last updated February 5, 2026, states it in one sentence: “Certificates included in the Chrome Root Store must provide value to Chrome end users that exceeds the risk of their continued inclusion.” That inverts the old assumption. A CA is not entitled to inclusion by virtue of running a competent operation; it has to be worth the risk it adds, and every trusted root adds risk, because every trusted root can sign for any domain.

The program also pushed a set of structural changes under a banner it calls “Moving Forward, Together,” and the named goals read like a list of the failure modes the old system had. Single-purpose hierarchies, so a root used for TLS is not also used for email or code signing, with multi-purpose roots being phased out by the end of 2027. Mandatory automation, with applicant hierarchies expected to support automated issuance and renewal, ACME being the assumed mechanism. Term limits on roots: any root CA certificate whose key material was generated more than fifteen years ago gets removed on a rolling basis, and applicants must submit root keys generated within five years of applying. Multi-perspective domain validation, the requirement that a CA confirm domain control from several network vantage points so a localized BGP hijack cannot fool the check. These are not suggestions in a blog post. They are inclusion requirements with dated deadlines, and a CA that ignores them loses its place.

Trust-store events, 2017 to 2026 2017 Symantec plan set 2018 Chrome 66/70 distrust ships 2022 Chrome Root Store + TrustCor 2024 Entrust distrust 2025 47-day cert ballot passes root term limits begin 2026 *Three distrust events anchor the decade, bracketed by Chrome standing up its own store in 2022 and the Forum's move to short-lived certificates in 2025.*

2017 to 2018: Symantec, the one that proved the model

The clearest demonstration that a root program can end a CA’s business is Symantec. At the time it was one of the largest certificate authorities on the web, with roots that traced back through brands like VeriSign, Thawte, and GeoTrust. It did not lose its place over a single catastrophic breach. It lost it over a pattern.

The trigger was a public posting on January 19, 2017, calling attention to a series of questionable certificates from Symantec’s PKI. The investigation that followed, conducted in the open on Mozilla’s and Google’s public discussion forums, surfaced years of problems. Test certificates issued for domains the requesters did not control, including some for domains Symantec did not own. Misissuances traced back through Symantec’s network of registration authority partners. The numbers that came out of the review were not enormous in the abstract, dozens to a few hundred certificates depending on how you counted, but the issue was never the raw count. It was that a CA trusted to validate domain control had repeatedly failed to do so and had been slow to catch it.

Google’s response, laid out on the Chromium security blog and hammered out over months of public back-and-forth, was a graduated distrust rather than an overnight kill. Symantec agreed to hand new issuance to a managed partner CA while it rebuilt, and by December 1, 2017 it was supposed to stop issuing from its old infrastructure. Chrome then ramped down trust in two stages. Chrome 66, in the first half of 2018, distrusted Symantec certificates issued before June 1, 2016. Chrome 70, in late 2018, distrusted the rest. Firefox ran a parallel schedule across versions 60 and 63. Any site still on a Symantec certificate had to replace it or break.

The endgame was an acquisition. Symantec sold its certificate business to DigiCert, and because certificates issued through the managed transition and afterward chained to DigiCert’s roots rather than Symantec’s, they were unaffected by the distrust. The brand survived as a label; the trust did not transfer with it. The lesson the rest of the industry took was sharp. A root program will absorb a slow, public, multi-month fight and still pull the trigger, and being one of the largest CAs on the web is no protection if you cannot demonstrate that your validation works.

2022: TrustCor, removed on suspicion

Symantec was about demonstrated misissuance. TrustCor was about something harder to pin down and arguably more alarming: who actually controls a trusted root, and what they might do with it.

In November 2022, researchers including a University of Calgary professor raised concerns on Mozilla’s dev-security-policy forum about TrustCor, a CA whose roots were in the major stores. Reporting in the Washington Post connected the dots that drove the worry. TrustCor appeared to share corporate ties, ownership, and personnel with Measurement Systems, a company that had distributed an Android SDK containing spyware, and Measurement Systems was in turn linked to Packet Forensics, a firm that had marketed interception capability to government buyers. A messaging product associated with TrustCor was found to carry the same SDK. The company’s stated address was a mail drop, and the people listed in its leadership did not hold up to scrutiny.

None of that was proof that TrustCor had issued a fraudulent certificate. What it established was that an organization with apparent ties to the interception business held the power to sign a certificate for any domain on the web, and that the people accountable for the root could not be clearly identified. For a root program, that is enough. The trust model depends on a CA being who it says it is and being accountable; an anchor whose controllers are obscured and possibly adversarial fails the value-versus-risk test on its face. Mozilla set a distrust date, Microsoft acted on its own timeline, and Google announced Chrome’s distrust in December 2022. TrustCor wound down. The case is the cleanest illustration that trust in this system is about accountability of the operator as much as the correctness of any particular certificate.

2024: Entrust, the slow accumulation

Entrust is the most recent removal of a long-established CA, and it followed the Symantec template closely enough to feel like a sequel. Entrust was one of the older names in the business. It lost Chrome’s trust the same way Symantec did: a pattern that accumulated past the point a root program would tolerate.

On June 27, 2024, Google’s security blog announced that Chrome would stop trusting new TLS certificates from Entrust and its AffirmTrust roots. The stated reason was not a single breach but, in Google’s words, “a pattern of compliance failures, unmet improvement commitments, and the absence of tangible, measurable progress in response to publicly disclosed incident reports” observed over the preceding six years. The technical specifics behind those incidents included certificates issued without the serverAuth extended key usage, which makes them unsuitable for TLS server authentication in the first place, and certificates that used a weaker signature configuration than the applicable policy required. Individually, fixable mistakes. In aggregate, and set against the standard that a publicly-trusted CA owes the ecosystem, enough.

The mechanism was the now-familiar grandfather clause. Certificates issued on or before October 31, 2024 stayed trusted until they expired. Certificates Entrust issued from November 1, 2024 onward would not be trusted, with the block landing in Chrome 127 and later across Windows, macOS, ChromeOS, Android, and Linux. Site operators using Entrust were told to move to another CA before their existing certificates expired. As with Symantec, the practical exit was to lean on a competitor; Entrust arranged to issue from another CA’s roots to keep its customers covered while it sorted out its standing.

What ties the three events together is the absence of drama in the mechanism. There is no emergency switch that nukes a CA mid-handshake. There is a public record of incidents, a policy that says value must exceed risk, a deliberate and dated distrust schedule that protects existing certificate holders, and a software update that ships the decision. The CA gets months of warning and a clear bar to clear. When it cannot clear the bar, the trust ends on a calendar date, and the rest of the web keeps working because the leaf certificates already issued ride out their remaining life.

The fight moved to certificate lifetimes

The newest pressure on the system is not about which CAs to trust but about how long any single certificate should be trusted. The logic is straightforward. Revocation has never worked well at web scale; browsers check it inconsistently, soft-fail when the check times out, and the whole revocation-check path is itself a fingerprint and a performance cost. If certificates are short-lived, a mistaken or compromised certificate expires on its own before the revocation machinery would have mattered, and the value of fast, reliable revocation drops because the window of exposure is small to begin with.

That argument won. On April 11, 2025 the CA/Browser Forum passed ballot SC-081v3, originated by Apple, with 29 votes in favor and none against. It sets a phased reduction of the maximum TLS certificate lifetime: down to 200 days as of March 15, 2026, to 100 days as of March 15, 2027, and to 47 days as of March 15, 2029, with the window for reusing domain validation data shrinking to 10 days at the end. A 47-day certificate is a certificate you cannot renew by hand. Automation stops being a nice-to-have and becomes the only way to operate, which is exactly why the Chrome program made ACME support an inclusion requirement before the lifetime ballot landed. The pieces were placed in order.

Shorter certificates also change what an observer sees on the wire. More frequent reissuance, more automated renewal traffic, and the steady churn of the handshake parameters that come with it all shift the fingerprint surface, which intersects with the material in The TLS 1.3 handshake, frame by frame. And the same governance bodies are already steering the next change, the move to post-quantum key exchange, covered in Post-quantum TLS: ML-KEM, X25519MLKEM768, and the hybrid handshake. The trust store is the slowest-moving part of this stack, and even it is being told to rotate its roots on a fifteen-year clock now.

What the trust store really is

Strip away the cryptography and the trust store is a governance artifact. A few hundred entries, each one a decision by a browser or OS vendor that a particular organization is competent and accountable enough to vouch for identities across the entire web, revisited continuously, revocable at any time, and increasingly run from a shared database so the four big programs do not drift apart. The cryptography makes the chain checkable. The store is what decides whose signatures count, and that decision is human, political, and enforced by the threat of removal rather than by any law.

The three distrust events are the proof the system has teeth. Symantec, one of the largest CAs on the web, gone over a pattern of validation failures. TrustCor, removed not for a proven bad certificate but because no one could say who really controlled its roots. Entrust, an old name worn down by six years of incidents that never added up to a single disaster but added up nonetheless. In each case the trigger was the same standard the Chrome program now writes in one line: a root has to be worth more than the risk it carries, and any root that can sign for every domain on the internet carries a lot. The most important property of the web’s trust store is not that CAs are in it. It is that they can be taken out, on a schedule, in public, and the web keeps loading.

Sources & further reading

Further reading