What a Certificate Authority Root Is
A Certificate Authority Root is the topmost certificate in a chain of trust. It is a self-signed certificate that a Certificate Authority (CA) uses to sign intermediate certificates, which in turn sign the TLS/SSL certificates that authenticate websites and services. When your browser or operating system trusts a website, it is ultimately trusting the root certificate that anchors that chain.
More from this site
Keep reading the latest coverage
Roots are not issued to domain names; they are issued to organizations, typically CAs themselves. Because a root certificate carries ultimate signing authority, its protection is the single most important part of public key infrastructure (PKI).
How the Chain of Trust Works
Every TLS connection follows a path from the leaf certificate (the one presented by the server) back through intermediate certificates to a trusted root. Browsers and operating systems maintain a trust store, a curated list of root certificates they are willing to accept. If the chain ends at a root in that store, the connection is considered valid. If it ends at a root not in the store, users see a warning.
Most public CAs operate one or more intermediate certificates rather than signing end-entity certificates directly with the root. This limits the exposure of the root private key, which should be kept offline in a hardware security module (HSM) or an air-gapped system.
Root Certificates in Operating Systems and Browsers
Each platform maintains its own root program and trust store:
- Apple issues root certificates through its Apple Root Certificate Program and ships them in macOS and iOS.
- Microsoft maintains the Trusted Root Certificate Program, which populates the Windows trust store.
- Google Chrome uses its own set of roots, maintained by Google Trust Services, rather than relying solely on the operating system.
- Mozilla Firefox uses its own curated root store, independent of the OS.
A root must be included in these stores for the certificates it signs to be trusted by default. Inclusion is not automatic; CAs apply and undergo audits before their roots are added.
Why Root Security Is Critical
A compromised root private key would allow an attacker to impersonate any website or service that chain traces back to that root. For this reason, root keys are handled with extreme care:
- They are generated in secure facilities, often with multiple custodians.
- They are stored offline, typically in FIPS 140-2 Level 3 or higher HSMs.
- They are used sparingly, only to sign intermediate certificates.
- Certificate Transparency logs monitor all certificates issued by the CA, helping detect misuse.
Root Certificate Lifetimes and Rotation
Historically, root certificates had lifetimes of 10 years or more. In recent years, the industry has moved toward shorter lifetimes, often 5 to 7 years, to allow faster rotation if a root is suspected to be weak or compromised. Major CAs such as DigiCert, GlobalSign, and Let's Encrypt (via its ISRG Root X1) have adopted these shorter windows.
When a root reaches the end of its life, it is replaced by a new root. The transition requires that the new root be pre-installed in trust stores, and that all intermediate certificates be re-signed under the new root. This process is complex and can take years to complete without breaking trust for users on older systems.
What Happens When a Root Is Removed
Trust stores can remove a root if a CA misbehaves or if the root is found to be insecure. Removal means that any certificate chain ending at that root will no longer be trusted. This has happened several times in the industry, most notably when WoSign and StartCom roots were distrusted by Apple, Google, and Mozilla after violations of certificate issuance policies.
Distrust is a severe action. It breaks HTTPS connections for any server using a certificate chain rooted at that CA, and it requires the CA to reissue certificates under a different, trusted root.
How to Verify a Root Certificate
You can inspect the root certificate in a chain using browser developer tools or command-line utilities like openssl. In a browser, click the padlock icon, view the certificate details, and trace the chain upward until you reach a self-signed root. The root should match a known entry in your operating system or browser trust store.
For organizations managing internal PKI, root certificates are distributed through group policy or mobile device management (MDM) profiles so that devices trust internally issued certificates. These private roots are not publicly trusted and must be manually deployed.