Back to Interactive Demo
CertificatesTrust

Root Stores & Trust Anchors: Complete Guide

Understand how browsers decide which certificates to trust. Learn about root store programs, CA inclusion policies, and what happens when CAs misbehave.

10 min readDecember 2025
Root Stores and Trust Anchors Visualization

Quick Answer: What is a Root Store?

A Root Store (or Trust Store) is a collection of root CA certificates that your device or browser trusts. When you visit an HTTPS site, your browser checks if the certificate chains back to one of these trusted roots.

When your browser shows 🔒 for https://example.com...

It's because the certificate chains to a root CA in your trust store

Your device has ~100-150 root CAs pre-installed by the OS or browser vendor

If certificate chains to one → Trusted. If not → WARNING!

Key Point: Root stores are managed by operating system vendors (Microsoft, Apple) or browsers (Mozilla, Google). Each has its own inclusion criteria and policies.

Major Root Store Programs

ProgramUsed ByUpdated Via
Microsoft Root ProgramEdge, IE, Windows apps, .NETWindows Update
Apple Root ProgramSafari, iOS apps, macOS appsOS updates
Mozilla Root StoreFirefox, Thunderbird, many Linux distrosFirefox releases
Chrome Root StoreChrome, Chromium browsersChrome releases
Java cacertsAll Java applicationsJDK releases

Java Trust Store Warning

The Java cacerts trust store is often outdated in old JDKs. If you're running legacy Java applications, newer CAs like Let's Encrypt might not be trusted. Always keep your JDK updated!

How Chain Validation Works

When you connect to an HTTPS site, your browser validates the entire certificate chain from the server's certificate up to a trusted root.

Step 1: Server Presents Certificate

Server sends its leaf certificate plus any intermediate certificates needed to build the chain to a root CA.

Step 2: Browser Builds Chain

Browser links: Leaf → Intermediate(s) → Root CA. Each certificate is signed by the one above it in the chain.

Step 3: Check Root Store

Browser asks: "Is the root CA at the top of this chain in my trust store?"

Step 4: Validate Chain

If root is trusted, verify: all signatures valid, nothing expired, nothing revoked. If all checks pass → Secure connection!

Root Found

www.example.com → Intermediate → Root CA → [In Trust Store]

✓ Secure Connection

Root NOT Found

www.example.com → Intermediate → Unknown Root → [NOT in Trust Store]

NET::ERR_CERT_AUTHORITY_INVALID

CA Distrust Incidents

When CAs violate policies or suffer security breaches, browsers remove them from their trust stores. This is rare but has happened to major CAs.

DigiNotar2011

Event: Hackers issued rogue certificates for Google and other domains

Impact: Enabled surveillance of users in Iran

Outcome: Complete distrust, company went bankrupt

Symantec2017-18

Event: Multiple certificate mis-issuance incidents

Impact: Largest CA at the time (~30% of all certificates)

Outcome: Gradual distrust over 2 years, sold CA business to DigiCert

WoSign/StartCom2016

Event: Backdating certificates, ownership deception

Impact: Free certificate providers in China

Outcome: Distrusted by Mozilla, then others. Both CAs ceased operations

What Happens During Distrust

  1. Browser vendor announces distrust with deadline
  2. Grace period for site owners to get new certificates
  3. Old certificates stop working on deadline
  4. All affected sites must get certs from a new CA

How CAs Get Into Root Stores

Becoming a trusted root CA is a rigorous, multi-year process. CAs must meet strict security and operational requirements.

1

AUDIT

WebTrust or ETSI audit. Annual compliance reviews. Costs ~$100,000+/year for audits.

2

APPLY

Submit to each root program (Microsoft, Apple, Mozilla, Google). Provide audit reports, policies, insurance.

3

REVIEW

Program reviews application. Public discussion (Mozilla). Technical evaluation. Can take 1-2+ years.

4

INCLUSION

Added to next root store update. Propagates to all users via updates. Now trusted globally!

5

ONGOING

Annual audits. Incident reporting. Policy compliance. Can be removed for violations.

Viewing Your Trust Store

Windows
certmgr.msc
# Navigate to: Trusted Root CAs
macOS
# Open: Keychain Access
# Navigate to: System Roots
Linux
ls /etc/ssl/certs/
# or
ls /etc/pki/tls/certs/
Firefox
about:certificate
# In address bar

Java Trust Store

# View Java cacerts
keytool -list -cacerts

# With password (default is "changeit")
keytool -list -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit

# List specific CA
keytool -list -cacerts | grep "DigiCert"

Enterprise Trust Management

Enterprises often need to add their own root CAs for internal PKI, development environments, or HTTPS inspection.

Why Enterprises Add Custom Roots

  • • Internal CAs for intranet sites
  • • Employee certificate PKI
  • • Development and testing
  • • HTTPS inspection (corporate proxy)

DANGER: Adding Root CAs

Anyone with a root CA in your trust store can:

  • • Issue certificates for ANY domain
  • • Perform undetectable man-in-the-middle attacks
  • • Sign malware that appears trusted

Only add roots you fully control and trust!

Adding a Custom Root CA

# Linux (Debian/Ubuntu)
sudo cp my-root-ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

# Linux (RHEL/CentOS)
sudo cp my-root-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

# Java
keytool -importcert -trustcacerts -keystore $JAVA_HOME/lib/security/cacerts \
  -storepass changeit -alias "My Root CA" -file my-root-ca.crt

Frequently Asked Questions

Why does Firefox have its own root store?

Mozilla maintains its own root store (NSS) to ensure consistent trust across all platforms and to apply its own security policies. This means Firefox on Windows might trust different CAs than Edge or Chrome.

What is Chrome Root Store?

Chrome historically used the OS root store, but is transitioning to its own Chrome Root Store for more consistent security across platforms. This is rolling out gradually.

Can I remove a root CA from my trust store?

Yes, but be careful. Removing a legitimate root CA will break HTTPS for all sites using certificates from that CA. Only remove roots you're certain you don't need.

Why did my Java app stop trusting Let's Encrypt?

Likely you're using an old JDK. Let's Encrypt's ISRG Root was only added to Java in recent versions. Update your JDK or manually add the ISRG root to your cacerts.

Related Resources

Explore Root Store Programs

See how different browsers and platforms manage trust, and watch the chain validation process.

Open Root Stores Demo