Certificate trust stores and root CA management: auditing roots, chains and private CAs everywhere

Every TLS connection, signed update and certificate-based login your estate makes is only as trustworthy as the list of root certificates the client accepts, and most organisations have never inventoried those lists. Trust stores live in operating systems, browsers, language runtimes, container images and appliances, and each one is managed by a different root programme or a different team. This guide explains how the Microsoft, Apple, Mozilla and Chrome root programmes decide what your devices trust, how intermediate chains and enterprise private roots fit in, and how to audit and maintain trust stores as an operational control. It is written for PKI engineers, platform and endpoint teams, and security architects who own machine identity. For the basics of chains and X.509, read the PKI Basics Guide first.

Key takeaways

• There is no single trust store. Windows, Apple platforms, Chrome, Firefox, Linux distributions, Java, Node.js and Python packages each carry their own list, and an application can silently use a different one from the operating system it runs on.
• Root programmes are tightening fast. Chrome and Mozilla now remove roots once their key material is 15 years old, and Chrome, Mozilla and Apple are forcing TLS hierarchies to be dedicated to server authentication only, so public roots will change more often than they used to.
• Distrust is usually gradual, not a hard cut. Chrome uses an SCTNotAfter constraint and Apple can refuse leaf certificates signed after a configured date, so existing certificates keep working while new ones fail. Your monitoring must check issuance dates, not only expiry.
• Private roots are high-value credentials. An enterprise root pushed to every device by Group Policy or MDM can impersonate any site to those devices. Constrain, inventory and monitor it like a privileged account.
• Trust store drift is an attacker technique. Installing a rogue root (MITRE ATT&CK T1553.004) lets an adversary intercept TLS or make malware look signed, so unexpected additions to root stores belong in your detection content.

How trust stores and root programmes work

A trust store is a set of trust anchors, usually self-signed root CA certificates, plus metadata saying what each anchor may be used for. When a client validates a server certificate it builds a path from the leaf, through one or more intermediate CAs, to an anchor in its store, then checks validity dates, key usage, extended key usage (EKU), name constraints and revocation. If no path reaches a trusted anchor, validation fails, regardless of how correct the certificate is.

Public roots get into stores through root programmes run by the platform owners. Each programme publishes a policy, requires annual audits against WebTrust or ETSI criteria, and uses the Common CA Database (CCADB), operated by the Linux Foundation, to record root and intermediate certificates, audits and incidents. Programmes act independently: a CA can be distrusted by one store and remain in another for months.

The four major root programmes compared

The practical consequence of the term limits is a steady flow of root replacements. Chrome's published schedule removes roots with key material from 2006 to 2007 on 15 April 2026, 2008 to 2009 on 15 April 2027, 2010 to 2011 on 15 April 2028 and 2012 to mid-2014 on 15 April 2029. Any server still serving a chain to one of those roots, or any client pinned to it, needs a plan before those dates. The Certificate Expiry Outages and 47-Day TLS Certificates Guide covers the matching shrinkage of leaf lifetimes.

Where trust stores live in a real estate

Inventory starts with knowing which store each component actually consults. The table below lists the common locations and the tool used to inspect each one.

The pattern to notice is that containers and runtimes freeze a copy of a root list at build time. A container image built in 2022 still carries 2022 roots in 2027, after several public roots have been removed and replaced. See the Container Image Security Guide.

Intermediate chains: what servers must send

Clients usually hold roots, not intermediates, so the server must present the leaf plus every intermediate up to (but normally not including) the root.

• Missing intermediate: some clients fetch the issuer through the Authority Information Access (AIA) URL or cache intermediates they have seen before, others do not. A server that omits the intermediate can pass a desktop browser test and fail every API client, mobile app and Java service. Always configure the full chain.
• Cross-signed paths: a new root is often cross-signed by an older one so older clients can still build a path. When the old root expires or is removed, clients that only know the old root fail, while modern clients choose the newer path. Know which path your servers advertise and which clients still depend on the cross-sign.
• Wrong purpose: with Chrome, Apple and Mozilla all moving to single-purpose hierarchies, intermediates that carry clientAuth alongside serverAuth will be phased out. Public TLS certificates will stop being usable for mutual TLS client authentication. Plan private PKI for client certificates. See the mTLS Guide.
• Pinning: applications that pin an intermediate or root break when the CA rotates. Pin to keys you control, or do not pin.

Enterprise private roots

Private roots underpin internal TLS, Wi-Fi (EAP-TLS), VPN, smart card logon, device certificates and TLS inspection. The Chrome policy explicitly excludes enterprise CAs that issue only to internal resources, so the root programme rules do not protect you here: your own governance does. Design and ceremony detail is in the Enterprise PKI Design and CA Hierarchy Guide and the Private CA Design and Operations Guide. Trust store management adds these rules:

• Distribute narrowly: deploy a private root only to the device groups that need it, through one mechanism (Group Policy Public Key Policies or an MDM trusted certificate profile), never by asking users to install it.
• Constrain what it can vouch for: issue internal TLS from an intermediate with name constraints limited to your internal domains, so a compromised issuing CA cannot mint certificates for external names. Chrome's certificate manager also lets administrators constrain locally trusted certificates.
• Separate purposes: keep TLS inspection roots, device identity roots and code signing roots apart. A TLS inspection root on every laptop is the most dangerous credential in many estates. See the TLS Inspection Guide.
• Know local trust behaviour: Chrome on Windows and macOS honours roots added to the OS stores (Trusted Root Certification Authorities, Enterprise Trust and the Group Policy variants on Windows; Always Trust settings in the System keychain on macOS) for TCP-based TLS, and honours local distrust from the Untrusted Certificates store. For QUIC it only honours local removal of trust, which can surprise teams running TLS inspection.
• Plan removal at creation: record which groups received each private root, which services chain to it, and how it will be withdrawn. Group Policy certificate settings and the auto-update registry settings persist after a GPO is unlinked, so removal must be an explicit action.

Where identity fits

Every root and intermediate in a store is a machine identity that other machines rely on, and the private keys behind enterprise roots are among the most privileged non-human credentials an organisation holds. Whoever can add a root to a fleet's trust store, through Group Policy, MDM or a golden image, can make that fleet accept forged identities for any service. Treat those administrative paths as privileged access, put CA keys in hardware security modules with dual control, and include trust anchors in the machine identity inventory. See the Machine Identity, PKI and Certificate Lifecycle Guide and the Microsoft Intune Guide.

Trust store hygiene and audit

Hygiene means each store contains only the anchors it needs, from a known source, at a known version. An audit answers four questions for every store: what is in it, where did each entry come from, is the platform list current, and has anything been added locally.

1. Build the inventory. List store types by asset class (Windows endpoints and servers, macOS and mobile, Linux hosts, container base images, Java and other runtimes, appliances). For each, record the update mechanism and the owning team.
2. Baseline platform roots. On Windows, run certutil -verifyCTL AuthRoot and certutil -verifyCTL Disallowed and check lastsynctime to prove automatic updates are working. For disconnected networks, use certutil -syncWithWU to a share and point clients at it with the RootDirUrl setting, scheduled daily. For Apple platforms, compare against Apple's published root list for the OS release. For Linux, check the ca-certificates package version.
3. Find local additions. Diff each machine's Root and CA stores against the platform baseline plus your approved private roots. Anything else is either shadow IT (developer proxies, old inspection appliances, vendor agents) or an attacker. On Linux, review /usr/local/share/ca-certificates and /etc/pki/ca-trust/source/anchors.
4. Scan images and runtimes. Extract CA bundles from container images and application packages, record their age, and flag any older than your agreed threshold. Check Java cacerts on servers separately from the OS store.
5. Check server chains. Scan your public and internal endpoints for incomplete chains, chains to roots on a published removal schedule and certificates from CAs under phase-out. Certificate Transparency logs help for public names: see the Certificate Transparency Monitoring Guide for Web Teams.
6. Remove and restrict. Remove unapproved roots in pilot rings first. Where you must keep a platform root but not trust it for a purpose, use the platform's own controls (Untrusted Certificates on Windows, deactivating the entry in /etc/ca-certificates.conf on Debian) rather than deleting files that the package manager will restore.
7. Repeat on a schedule and on events. Re-run the audit quarterly, after any root programme distrust announcement, and after onboarding a new security agent or appliance that might install its own root.

Rolling out a trust change safely

• Audit mode first: before removing a root, search logs and scan results for chains that use it.
• Pilot rings: apply additions and removals to a small IT ring, then a broader early adopter ring, then the fleet, with a pause long enough to see failures from scheduled jobs.
• Rollback: keep the exported certificate and the exact GPO or profile version so a removal can be reversed within one policy refresh.
• Distrust events: when a public CA is distrusted, follow the CA Compromise and Mass Certificate Replacement Playbook. Because Chrome and Apple distrust by issuance date, certificates issued before the cut-off keep working, which buys time but hides the problem until renewal.

Decision guidance

Small organisations: rely on platform updates, keep at most one private root, and make the audit a quarterly script plus a check of container base images. Large organisations: assign an owner per store type, feed trust store state into the configuration management database, and subscribe to the root programmes' announcements (the GitHub repositories for Microsoft, Apple and Chrome, and Mozilla's policy page) so distrust events trigger change tickets.

Detection and measurement

• Root store changes: monitor additions under HKLM and HKCU\SOFTWARE\Microsoft\SystemCertificates\Root\Certificates (for example with Sysmon registry events) and keychain trust changes on macOS. MITRE ATT&CK T1553.004 Install Root Certificate describes this adversary behaviour; unexpected roots on a single host are a strong signal.
• Auto-update health: alert when the AuthRoot or Disallowed CTL lastsynctime on a Windows host is older than a few days.
• Validation failures: collect TLS handshake errors from proxies, load balancers and application logs, grouped by issuing CA, to spot chain and removal problems early.
• Interception signals: a certificate for a public site issued by an unknown CA, seen by an endpoint agent, indicates adversary-in-the-middle activity (T1557) or an unmanaged inspection device.

Metrics that show the control is working:

• Percentage of assets whose trust store matches the approved baseline (target 100 percent for servers).
• Number of unapproved roots found per audit, trending to zero.
• Median age of CA bundles in container images and runtimes.
• Number of endpoints serving incomplete chains or chains to roots with a published removal date.
• Time from a root programme distrust announcement to completed impact assessment.

Framework mapping

Common failure patterns

• Testing only in a browser. A chain that validates in Chrome because of cached intermediates fails in Java, curl and mobile apps. Test with clients that do not fetch missing intermediates.
• Frozen bundles in images and appliances. Base images and firmware carry root lists that never update, so a public root rotation becomes an outage years later in a forgotten service.
• Inspection roots everywhere and forever. TLS inspection roots deployed to all devices, including servers and build agents, outlive the appliance that used them and remain trusted with keys nobody tracks.
• Disabled auto-update without a replacement. Windows automatic root update turned off in a hardening baseline, with no internal CTL distribution, leaves machines without new roots and, worse, without the Disallowed list.
• Private CA key compromise treated as a certificate problem. Losing a private root or issuing CA key is a fleet-wide identity compromise, as shown by incidents where stolen signing keys were used to forge trust, such as the Microsoft Storm-0558 Key Breach 2023. Prepare a replacement and distrust procedure before you need it.
• Relying on public certificates for client authentication. Services that accept public TLS certificates as client identities will break as public hierarchies drop clientAuth.

Practitioner checklist

• Inventory every trust store type in your estate, with its update mechanism and owner.
• Confirm Windows automatic root and Disallowed CTL updates are working, or that an internal CTL distribution point is synchronised daily.
• Diff each store against the platform baseline plus approved private roots, and investigate every unapproved root.
• Record each private root: purpose, devices that trust it, name constraints, key location, and withdrawal plan.
• Scan container images, Java cacerts and bundled runtime CA lists, and set a maximum bundle age.
• Scan public and internal endpoints for incomplete chains and chains to roots on a Chrome or Mozilla removal schedule.
• Move any client certificate authentication off public TLS certificates onto private PKI.
• Add T1553.004 detection for root store changes on Windows and macOS.
• Subscribe to the Microsoft, Apple, Mozilla and Chrome root programme repositories and policy pages, and tie distrust announcements to change tickets.
• Rehearse a trust change through pilot rings with a documented rollback.

Standards and references

• Google: Chrome Root Program Policy
• Mozilla: Root Store Policy
• Apple: Apple Root Program Policy
• Microsoft: Trusted Root Program Requirements
• Microsoft Learn: Configure trusted roots and disallowed certificates in Windows
• Chromium: Chrome Root Store FAQ
• Apple: Available root certificates for Apple operating systems
• CCADB: Common CA Database

Related NHI Mgmt Group resources: PKI Basics Guide · Enterprise PKI Design and CA Hierarchy Guide · CA Compromise and Mass Certificate Replacement Playbook · Certificate Revocation Guide · Machine Identity, PKI and Certificate Lifecycle Guide