What is a root certificate? Root CAs and the trust store

A root certificate is the certificate of a root certificate authority (root CA): a self-signed certificate at the top of a chain of trust. Browsers and operating systems trust it because it is built into their trust store, and every publicly trusted HTTPS certificate leads back to one through a certificate chain.

Also called

root CA certificate, trust anchor ^[2]

Issuer and subject

the same name, byte for byte; the root is signed with its own key (Baseline Requirements §7.1.2.1) ^[1][2]

CA flag

basic constraints extension, marked critical, with cA set to TRUE (§7.1.2.1.4) ^[1]

Validity of a new root

2922 to 9132 days, about 8 to 25 years (§7.1.2.1.1) ^[1]

Trusted for websites

until its key is more than 15 years old, in the Chrome and Mozilla root stores, under their transition rules ^[4][5]

Sent by servers

not needed: TLS 1.3 lets servers omit a trust anchor's certificate (RFC 8446 §4.4.2) ^[3]

How a root certificate works

A website's certificate is signed by an intermediate certificate authority, and the intermediate is signed by a root. To trust the site, a client checks each signature up to a certificate it already trusts: the root, which shipped with the browser or the operating system.

A root is self-signed: its issuer and subject are the same, and its signature verifies with the public key it carries (RFC 5280 §3.2) ^[2]. Any certificate can be self-signed, as on self-signed certificates, so a root is trusted not for its signature but because a trust store includes it, after its authority passed that store's checks.

Under the Baseline Requirements a root CA signs a certificate only when an authorised person deliberately issues a direct command for that signature (§4.3.1.1), and like every CA key it sits in a cryptographic module validated to at least FIPS 140-2 or FIPS 140-3 level 3, or to a Common Criteria evaluation at EAL 4 or higher (§6.2.7) ^[1]. Day-to-day issuance uses intermediate keys, so a compromised intermediate can be replaced without touching the root in trust stores. What a root key may sign, and how root systems must be separated from the rest of the network, is on certificate authorities.

What a root certificate looks like

On this Linux Mint machine, an Ubuntu derivative, the root files in /etc/ssl/certs/ are links into the Mozilla set that the ca-certificates package installs under /usr/share/ca-certificates/mozilla/ ^[6][13]. The output below is from the lab root used later:

$ openssl x509 -in root2.pem -noout -subject -issuer
subject=O = Example Lab, CN = Example Root CA 2
issuer=O = Example Lab, CN = Example Root CA 2
$ openssl x509 -in root2.pem -noout -ext basicConstraints,keyUsage
X509v3 Basic Constraints: critical
    CA:TRUE
X509v3 Key Usage: critical
    Certificate Sign, CRL Sign

CA:TRUE says the key may sign certificates, and Certificate Sign with CRL Sign are the two key usages the Baseline Requirements require of every CA certificate (§7.1.2.10.7) ^[1]. A self-signed certificate also verifies against itself:

$ openssl verify -CAfile root2.pem root2.pem
root2.pem: OK

A website certificate shows its issuing CA as issuer and CA:FALSE; the Baseline Requirements allow it to omit basic constraints, but never to set cA to TRUE (§7.1.2.7.8) ^[1][13].

Root, intermediate and leaf

The validity row comes from §7.1.2.1.1, §7.1.2.10.1 and §6.3.2 ^[1]. A server that omits its intermediate breaks the chain for clients that lack it; in curl, Git or Python the symptom is unable to get local issuer certificate.

Trust stores: who decides which roots are trusted

A trust store, also called a root store, is the list of root certificates a client trusts. Each root program below runs a store used on the web:

• Mozilla maintains the store built into Firefox, also used in other companies' products ^[6]. Debian's ca-certificates package, also used by Ubuntu, ships it ^[13].

• Apple maintains one root store for all its operating systems, macOS and iOS included ^[7].

• Microsoft maintains the Windows store, called Trusted Root Certification Authorities ^[8].

• Google maintains the Chrome Root Store, which Chrome uses on Windows, macOS, ChromeOS, Linux and Android instead of the operating system's list. Apple's policies keep it out of Chrome for iOS ^[9].

Before a root goes in, its authority must pass independent audits and follow the CA/Browser Forum Baseline Requirements and the program's own policy.

How roots lose trust

Roots do not stay trusted for their whole validity. Chrome removes a root whose key material was generated more than 15 years ago (Chrome Root Program Policy 1.8, §1.3.1.2), and Mozilla removes the websites trust bit at the same age (Mozilla Root Store Policy 3.1, §7.4); older roots follow transition schedules ^[4][5]. A 25-year root can therefore lose website trust long before it expires; Chrome allows temporary extensions case by case ^[5].

Programs also remove a root, or stop trusting its new certificates, when an authority breaks the rules. Chrome 70 fully removed trust in Symantec's old infrastructure and the certificates chaining to its roots, with a small set of exceptions. Chrome 131 and later do not trust by default new certificates that chain to a set of Entrust roots, while certificates logged before the cut-off keep working ^[10].

Clients on the same machine can hold different stores:

• Firefox carries Mozilla's roots in its own library ^[6];

• Java uses its own cacerts keystore ^[11];

• Python's requests uses the certifi package ^[11].

How to see the trusted roots on a device

• Windows. Run certlm.msc for the machine's certificates and open Trusted Root Certification Authorities, Certificates. certmgr.msc shows the current user's store ^[8].

• macOS. security dump-trust-settings -s shows the trusted system certificates; -d shows those an administrator added ^[11].

• iPhone and iPad. The roots Apple ships are listed on Apple's support site ^[7]. Roots installed with a profile appear under Settings, General, About, Certificate Trust Settings ^[11].

• Linux. Debian and Ubuntu keep the system bundle in /etc/ssl/certs/ca-certificates.crt; Fedora and RHEL keep theirs under /etc/pki/ca-trust/ ^[11].

• Firefox. It keeps its own store; the Certificates enterprise policy can make it trust roots added to the operating system store on Windows and macOS (ImportEnterpriseRoots) ^[11].

To check whether a root is in the Linux bundle, print every certificate's subject and search for the name; no output means it is not there, as for the lab root here ^[13]:

$ awk -v cmd='openssl x509 -noout -subject' '/BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep -i 'Example Root CA'

Which root a website chains to

The depth= lines are the path your client built, top first; the numbered s: and i: lines are what the server sent. A lab server sends a leaf, its intermediate and Example Root CA 2 cross-signed by Example Root CA; the client trusts only Example Root CA 2:

$ openssl s_client -connect localhost:8443 -servername www.example.test -CAfile root2.pem -showcerts </dev/null 2>&1 | grep -E '^depth=|^ [0-9] s:|^   i:'
depth=2 O = Example Lab, CN = Example Root CA 2
depth=1 O = Example Lab, CN = Example Issuing CA
depth=0 CN = www.example.test
 0 s:CN = www.example.test
   i:O = Example Lab, CN = Example Issuing CA
 1 s:O = Example Lab, CN = Example Issuing CA
   i:O = Example Lab, CN = Example Root CA 2
 2 s:O = Example Lab, CN = Example Root CA 2
   i:O = Example Lab, CN = Example Root CA

The path ends at depth 2 with the self-signed Example Root CA 2 from the client's store, though the last certificate sent names Example Root CA as issuer. That is a cross-certificate: its issuer and subject are different CAs ^[2]. A client trusting only the old root follows it to depth=3, Example Root CA ^[13]. More commands are on OpenSSL commands.

How to add a private root certificate

Organisations run private certificate authorities for internal sites, devices and mutual TLS. Their certificates are trusted only where the private root is installed.

Windows, as administrator ^[11]:

certutil -addstore -f Root company-root.cer

macOS, adding it to the admin trust settings ^[11]:

$ sudo security add-trusted-cert -d -r trustRoot company-root.cer

Debian and Ubuntu (PEM, file name ending in .crt) ^[11]:

$ sudo cp company-root.crt /usr/local/share/ca-certificates/
$ sudo update-ca-certificates

Fedora and RHEL ^[11]:

$ sudo cp company-root.crt /etc/pki/ca-trust/source/anchors/
$ sudo update-ca-trust

iPhone and iPad. Install the profile containing the root, then turn on full trust for it under Settings, General, About, Certificate Trust Settings ^[11].

Applications with their own store need the root added to it: Firefox through the Certificates → Install enterprise policy ^[11], Java with keytool -importcert -cacerts, and Node.js, curl, Git or Python as described on unable to get local issuer certificate.

When a root expires or is replaced

Roots expire too, and the transition can break old devices. Authorities prepare ahead: the old root cross-signs a new one, so clients without the new root still reach a root they trust ^[12]. Mozilla asks operators to apply with the successor at least two years before the old root's distrust date ^[4].

Take Let's Encrypt, a free SSL certification authority run by the nonprofit Internet Security Research Group ^[12]. Its older chain led to the root DST Root CA X3 through a cross-sign. When that cross-sign expired, devices with the newer ISRG Root X1 in their store were unaffected; some old devices without trust store updates started rejecting sites ^[12].

For site owners: serve the chain your authority currently provides, and keep your clients and devices receiving trust store updates. A chain that ends at an expired root gives the same error as any untrusted issuer, described on ERR_CERT_AUTHORITY_INVALID.

FAQ

Sources

1. CA/Browser Forum, Baseline Requirements (TLS), version 2.3.1: §4.3.1.1, §6.2.7, §6.3.2, §7.1.2.1, §7.1.2.7.8, §7.1.2.10.1, §7.1.2.10.7, §8.1.

2. IETF, RFC 5280, X.509 certificate and CRL profile: §3.2, §4.2.1.9, §6.1.

3. IETF, RFC 8446, TLS 1.3: §4.4.2.

4. Mozilla Root Store Policy, version 3.1: §7.4 Root CA Lifecycles.

5. Chrome Root Program Policy, version 1.8: §1.3.1.2 Root CA Term-Limit.

6. Mozilla wiki, CA and CA/FAQ: the NSS root store.

7. Apple, Available root certificates for Apple operating systems.

8. Microsoft Learn, Trusted Root Certification Authorities Certificate Store; How to view certificates with the MMC snap-in.

9. Chromium, Chrome Root Store FAQ.

10. Google Online Security Blog, Chrome's Plan to Distrust Symantec Certificates; Entrust Certificate Distrust.

11. Platform manuals: certutil (Microsoft), security(1) (Apple), update-ca-certificates(8), update-ca-trust(8), keytool (Oracle), Requests CA Certificates, Firefox enterprise policies (Mozilla), Apple certificate trust settings for iOS.

12. Let's Encrypt, DST Root CA X3 Expiration; About Let's Encrypt.

13. Our runs: OpenSSL 3.0.13 on Linux Mint 22.1, against the local ca-certificates package and a lab chain with test roots.