Every HTTPS connection rests on a question most people never think about: which certificate authorities does this device trust, and who decided? A short list of organizations makes that call on your behalf, through processes with names, rules, and public paper trails. Every few years one of those decisions gets reversed in a way that ends a company. This is how the lists are run.
A root store is the set of certificate authority keys your software accepts as trust anchors. When you connect to a website over HTTPS, the site presents a certificate chain, and validation succeeds only if the chain terminates in a root from that store. Everything else about web encryption, the ciphers, the handshake, the TLS version, sits downstream of one question: is the issuer on the list?
Four lists cover essentially everyone. Mozilla maintains one for Firefox, and because it is developed in the open it doubles as the trust base most Linux distributions ship in their ca-certificates packages. Apple and Microsoft each maintain stores for their operating systems. Google ran Chrome on the underlying platform's store until 2022, then launched the Chrome Root Program and moved the browser onto its own list. Android apps generally inherit the platform store, which is why a CA distrusted by browsers can linger longest on older phones that stopped receiving updates.
| Program | Covers | Process visibility |
|---|---|---|
| Mozilla | Firefox, Thunderbird, most Linux distributions downstream | Fully public: written policy, open discussion of inclusions and incidents, decisions argued in Bugzilla |
| Chrome Root Program | Chrome on all platforms since 2022 | Public policy; decisions announced by the program, rationale published |
| Apple | Safari, iOS, macOS | Published requirements and root list; deliberations internal |
| Microsoft | Windows, Edge | Published requirements and root list; deliberations internal |
The programs coordinate more than they used to. The Common CA Database (CCADB) is a shared repository where CAs file their audit statements, policy documents, and incident reports once for all the major programs, and the CA/Browser Forum, where CAs and browser vendors vote on the Baseline Requirements, sets the floor every public CA must meet: how domain control is verified, how long certificates may live (a ceiling that has been ratcheting steadily downward), what must happen after a key compromise.
What membership costs
Getting a root accepted takes years. The CA needs annual WebTrust or ETSI audits by accredited firms, a public certificate practice statement, and, for the Mozilla program, a public discussion period where anyone can raise objections on the record. Staying in is the harder part. CAs must log every certificate they issue to public Certificate Transparency logs (Chrome has refused to accept unlogged certificates since 2018), must respond to problem reports on fixed timelines, and must file public incident reports when they issue something they should not have. The incident reports are the system's connective tissue: a CA that makes a mistake and documents it thoroughly usually survives, because the programs treat the quality of the response as the signal.
The reason the bar is set there, rather than at perfection, is structural. Browsers cannot audit issuance directly; they see what CT logs and problem reports surface. What they can evaluate is whether a CA's story holds together over time: do the audits cover what they claim, do incidents get root-caused or excused, do the same failures recur. Trust in this system is an assessment of an organization's engineering culture, made from its paper trail.
The structural weakness: any trusted root can issue a certificate for any domain. There is no scoping by default: a small CA and the one your bank uses are equally able to mint a certificate for your mail provider. Certificate Transparency makes rogue issuance visible after the fact, and CAA records let a domain declare which CAs may issue for it, but the trust model's blast radius is still "the weakest CA on the list."
When trust gets withdrawn
Removal is rare, public, and terminal often enough that the case studies are worth knowing by name.
DigiNotar, 2011. The Dutch CA was breached and used to issue a fraudulent certificate for Google domains, which was then used to intercept the traffic of users in Iran. Browsers pulled the root within days of the discovery, and the company was bankrupt within the month. It remains the cleanest demonstration of both the stakes and the remedy.
Symantec, 2017 to 2018. At the time the largest commercial CA, Symantec was found to have issued test certificates for domains it did not control and to have delegated issuance with inadequate oversight. Google and Mozilla executed a staged distrust across browser releases rather than a cliff, giving sites time to re-issue elsewhere. Symantec sold its certificate business to DigiCert before the final deadline. The episode established that no CA is too big to remove, and that removal can be engineered gradually to protect site owners rather than the CA.
TrustCor, 2022. Reporting in The Washington Post, building on work by academic researchers, connected the CA to a company whose SDK had been found collecting user data from apps. No mis-issued certificate was ever produced; the programs concluded the relationships and the CA's answers about them were disqualifying on their own. Mozilla and Microsoft announced removal within weeks. The precedent: trust requires a credible operator, not just a clean issuance record.
Entrust, 2024. After a multi-year pattern of mis-issuance incidents, missed revocation deadlines, and incident responses the Chrome program judged insufficient, Google announced in mid-2024 that Chrome would stop trusting new Entrust TLS certificates issued after a cutoff that fall, with Mozilla following. Existing certificates were allowed to age out, and Entrust continued operating by issuing through another CA's roots. This one matters because the trigger was not a breach or a scandal but accumulated process failure, documented incident by incident in public.
Where the pressure comes from now
The open question for root programs is no longer whether they will police CAs; that is settled practice. It is whether they can keep the decision independent of governments. The EU's eIDAS regulation, in its Article 45 form, pushed browsers toward being required to trust member-state-designated authorities, a mandate browser vendors and security researchers publicly opposed on the grounds that a legally required root cannot be removed when it fails. The same tension appears wherever a government operates its own root: inclusion decisions become foreign policy, and the programs' only real power, the ability to say no, is exactly what legislation seeks to take away.
For an individual user there is little to configure here, and that is mostly the point: the system's value is that experts argue about CA failures in public so that you do not have to. The exceptions worth knowing are local. An employer or a piece of security software that installs its own root onto your machine has opted you into TLS interception that no root program reviewed, and an app that pins its certificates has decided not to inherit the problem at all. The list in your device is a governed object with a public history. Whether the governance holds is decided in venues most people never read, and it holds only as long as the programs keep the ability to say no.
Originally published at havenmessenger.com
