Root vs Intermediate Certificate Authority Guide

You open your bank’s website and log in without a second thought. But what makes your browser trust that the page really belongs to your bank and isn’t an imitation?

The answer lies in a chain of digital certificates, where root and intermediate certificates work together to establish the website’s trustworthiness.

Here’s how it works:

• A root certificate is a self-signed trust anchor that browsers and operating systems can trust.
• An intermediate certificate sits below it in the certificate hierarchy. A root CA signs it, and it passes that trust down to certificates used by websites, users, and devices.
• Together, the two certificates form a chain of trust that your browser validates when you connect to a website.

This article covers the fundamentals of root vs. intermediate certificates, the role of certificate authorities (CAs), how they work together in a certificate chain, and why SSL/TLS certificates are widely used to secure internet communications.

What Is a Digital Certificate?

A digital certificate is a secure way to verify the identity of entities that communicate online. Digital certificates use advanced, secure cryptography to provide an efficient way to manage users’ identities. This complex cryptography helps protect users from outside threats online.

Each certificate contains information about the holder, including their identity, public key, and validity period, along with details about the CA that issued it. That issuer field is where root and intermediate certificates come in, as it identifies the CA responsible for issuing and signing the certificate.

Organizations can replace traditional credentials (usernames and passwords) with digital certificates for enhanced authentication and security. For example, pairing 802.1X authentication with certificate-based protocols can support more robust identity verification for secure network connections.

Learn more about how certificates replace traditional passwords by watching the video below.

Differences Between Root and Intermediate CAs

Root vs. intermediate certificates serve different roles within a public key infrastructure (PKI) hierarchy, with differences in authority, security requirements, and the impact of a compromise. The table below highlights these key differences.

Feature	Root CAs	Intermediate CAs
Authority and Hierarchical Position	At the top of the certification authority hierarchy; they have the ultimate authority.	Sit below root CAs in the hierarchy; they derive their authority from a root CA.
Trust and Certification Paths	Serve as the starting point of trust; their root certificates are directly installed in trust stores.	Extend trust; their intermediate certificates are not directly installed in trust stores but are trusted through their chain back to a root CA.
Issuance Policies and Constraints	Subject to the most stringent issuance policies due to their foundational role in trust.	Operate under policies set by the root CA, with some flexibility based on the scope of their issuance.
Security Measures and Practices	Employ the most rigorous security practices to safeguard their private keys and root certificates.	Also maintain strong security measures but operate under the oversight of root CAs.
Scope of Issued Certificates	Typically do not issue root certificates widely; their primary role is to create intermediate CAs.	Actively issue end-entity certificates to websites, email servers, and users.
Audit and Compliance Requirements	Undergo the most strict audit requirements to ensure their operations and security measures are impeccable.	Subject to rigorous audits as well, but the focus is more on how they manage issuance and maintain the chain of trust.
Vulnerability and Compromise Impact	A compromise can have widespread implications, potentially undermining trust in a wide array of services and applications.	While a compromise is severe, its impact can be more contained, and the intermediate CA can be more easily replaced or its certificate revoked.

Client vs. Server Certificates

Before we define root certificates, intermediate certificates, and certificate authorities, let’s cover the difference between a client certificate and a server or SSL certificate. It’s pretty straightforward:

• The client certificate verifies the identity of the end-user device.
• The server certificate verifies the server’s identity.

Consider how the architecture of a web application works. It typically consists of a server that hosts the application, backend services that power its functionality, a database, and other supporting components. The web page, visual elements, and everything the end-user interacts with are part of the web client. This server-client relationship also shows up in how certificates are used.

In this setup, both the server and the client have their own certificates. Each certificate verifies the identity of its respective party. The client certificate verifies the end user’s identity, while the server certificate authenticates the website and the organization that owns it.

For example, if we search Wikipedia, the domain name “www.wikipedia.com” has an SSL certificate (HTTPS) that your web browser can use to verify that you are connecting to the Wikipedia page and not elsewhere.

What Are Certificate Authorities (CAs)?

Certificate authorities are trusted entities responsible for issuing digital certificates. These certificates serve as digital passports, providing authentication and enabling encrypted connections between web servers and browsers.

By verifying the identities of individuals and organizations, CAs help create a trusted environment for secure data exchange. They form the backbone of secure online communication, letting users confidently navigate the web, engage in e-commerce, and exchange information without fear of interception or fraud. Through rigorous validation, CAs maintain the internet's integrity and trustworthiness.

Let’s now look into root certificates and intermediate certificates.

What Are Root Certificate Authorities?

Root certificate authorities are the top-tier authorities in the certification hierarchy. They own the master certificates, the root certificates, that lie at the heart of trust for the internet.

These are self-signed certificates, meaning they’re issued and signed by the same CA; no extra steps are required to verify that certificate’s authenticity. Major browsers and operating systems pre-install trusted root certificates in their trust stores (also known as root stores), making them inherently trusted by devices worldwide.

Root certificates remain valid for as long as 9,132 days, or approximately 25 years. TLS subscriber (end-entry) certificates have a much shorter lifespan. As of 2026, those certificates have a cap of 200 days or less, and it will be reduced to 47 days in 2029.

The trust model of root certificate authorities relies on the trust software manufacturers, application developers, and end-users place in them. Many hardware and software manufacturers establish their own root programs to determine which CAs to include in their trusted CA store. For example, Microsoft maintains its own root store, as do Google and Apple.

Trusted CA certificates are embedded into browsers and devices, making them automatically trusted by users worldwide.

Root CAs are established through a rigid and secure process that involves generating a unique root certificate. The root certificate’s private key must be guarded with the highest level of security, as its compromise could undermine the trust model for every certificate issued under its hierarchy.

Despite their critical role, root certificate authorities do have limitations and vulnerabilities. The entire trust model relies on the secure storage and handling of the root certificate’s private key. Any compromise could have far-reaching implications for online security.

How Do Root Certificates Establish Trust?

Root certificate authorities lie at the foundation of the trust model. Their root certificates are the ultimate trust anchor against which all other certificates in the chain are validated. Since these root certificates come pre-installed in the trust stores of major browsers and operating systems, any certificate chain that links back to these root CAs is considered valid provided every certificate in the chain also passes signature, validity-period, and revocation checks.

This foundational trust is why root CAs operate under extremely strict guidelines to ensure the security and integrity of the root certificates they issue.

Why Are Root Certificates Important?

Root certificates matter because they’re the basis of online trust verification. Most browsers and devices automatically accept all certificates signed by a trusted root CA.

There are two specific contexts essential to root certificate trust:

1. Technical trust: Technical trust is a root CA’s adherence to security measures when issuing and managing certificates. It is the proven ability to follow protocol and ensure safe certificate practices.
2. Social trust: Social trust encompasses the public scrutiny of a CA’s trustworthiness. This includes its reputation in response to publicly available information on audits and compliance, as well as other influential factors of social acceptance: branding, client satisfaction, market performance, and more.

No CA is immediately trusted upon formation; it won’t enter trusted root stores until it develops both technical and social trust. Technical trust is demonstrated through adherence to strict security standards; as CAs undergo public scrutiny to develop technical trust, they naturally gain social trust.

This trust is vital because root CA attacks have far-reaching implications. If an attacker gains control of a root CA and starts issuing certificates, every device that trusts that root CA will accept those certificates — despite potentially dangerous consequences.

That’s why root CA security controls are different from intermediate CA controls.

What Are Intermediate Certificate Authorities?

Intermediate CAs serve as the bridge between the root certificate authorities and the end-user or server certificates. They operate under the authority of root certificate authorities but handle the day-to-day responsibilities of validating and issuing certificates to end entities. After performing the required checks and validations, they issue certificates to entities or individuals.

Intermediate CAs use certificates signed by a root CA, which provides assurance that they are trusted to issue secure, valid certificates. Intermediate certificates are typically valid for 5–10 years.

Unlike root certificate authorities, intermediate CAs can distribute certificates more freely and pose less risk to the overarching trust model if compromised because they are one step removed from the root CA.

How Do Intermediate Certificates Extend Trust?

Intermediate CAs extend this trust by issuing certificates to end entities and linking them directly to a root CA. This extension allows for more flexible, secure certificate distribution. It also helps root CAs keep their keys more secure by using them less often, reducing the risk of compromise.

Intermediate CAs act as a buffer, taking on the risks of certificate issuance while protecting the root certificate’s integrity.

Why Are Intermediate Certificates Important?

Root certificates represent inherent trust between services and end users. Intermediate certificates sit in the middle, reducing security risks and fraud through more frequent trust verification.

Intermediate certificates expire more frequently, are easier and faster to revoke when needed, and don’t put the trusted root certificate or the entire public key infrastructure (PKI) at risk if compromised — which simplifies security incident management and keeps costs low. That’s why most CAs use intermediate certificates alongside root certificates.

Benefits of Using Intermediate CAs

Using intermediate CAs offers a few key advantages:

• They reduce the risk to root CAs by acting as a buffer. If an intermediate CA is compromised, you can revoke its certificate without affecting the root certificate authority or other intermediate certificate authorities.
• This structure also enables more flexible certificate management and distribution, allowing businesses and organizations to issue certificates under the guidance of an intermediate CA without direct interaction with the more sensitive root CA.

What Is the Relationship Between Intermediate CAs and Root CAs?

The relationship between intermediate CAs and root CAs is symbiotic.

Root CAs provide the ultimate source of trust, while intermediate CAs extend that trust by issuing certificates down the certificate chain. This structure scales certificate issuance, as the root CA only needs to manage a relatively small number of intermediate CAs directly.

What Is the Difference Between a Chained Root and a Single Root?

A chained root is operated by an intermediate certificate authority that doesn't have its own trusted root. Instead, that intermediate CA is “chained” to a root CA, creating trust by association and allowing that intermediate CA to issue certificates.

A single root is owned by a CA, enabling direct certificate issuance. It is “unchained” since it doesn’t need to rely on another CA.

Chained roots add complexity to the certificate management process. Every server and app that uses these certificates must load the certificate to establish trust. Also, these certificates are intrinsically linked to the third-party CA, which creates two issues:

1. Chained intermediate certificates a expire before the root certificate does; these linked expiration dates can shorten intermediate certificate lifespans.
2. If the root CA goes out of business or loses trust, the chained root does, too — compromising the intermediate CA and all its certificates.

How Root and Intermediate Certificates Work Together: The Certificate Chain of Trust

In a public key infrastructure, certificates are issued in a specific order called a trust chain, or chain of trust. A chain of trust is a series of certificates linking an end-user or server certificate to a trusted root certificate. This trust chain ensures that any certificate is legitimate and can be traced back to a widely recognized, trusted root CA.

CAs build the certificate chains by issuing certificates signed with their private key. When a certificate is verified, the system checks the digital signature against the issuing CA's public key. If it matches, the process continues up the chain until it reaches a root certificate authority recognized by the device’s trust store.

In this diagram, you can see the order in which each certificate is issued within the certificate chain — and the reverse order in which they’re verified.

For example, any time a browser or client needs to verify the authenticity and security of a website, it does so through a specific certificate hierarchy:

1. Verify end-entity certificate: The website’s unique SSL/TLS certificate
2. Verify intermediate certificate: The certificate demonstrating the trustworthiness of the end-entity certificate and its issuing CA
3. Verify root certificate: The pre-installed certificate originating from the trusted root store of the client’s operating system and/or browser

If the verification process ends with a trusted root, the client will accept the certificate.

Why Every Enterprise PKI Needs an Offline Root CA

A public key infrastructure is only as secure as the certificate authorities that issue and sign certificates. That is why most enterprise PKI deployments use a hierarchy with an offline root CA and one or more online intermediate CAs. While this has long been considered a best practice, recent government guidance reinforces why it remains necessary for organizations adopting a zero-trust security model.

The NSA’s Zero Trust guidelines emphasize that every user, device, and application must be authenticated using trusted cryptographic identities. Since those identities depend on a PKI, protecting the certificate authority becomes a critical part of protecting the entire network.

This is where the separation between root and intermediate CAs becomes so important. The root CA is the trust anchor for every certificate in the environment.

If the root CA’s private key is compromised, attackers can create trusted certificates for virtually any device, server, or user, making the entire PKI untrustworthy.

Keeping the root CA offline greatly reduces this risk because it is isolated from everyday network activity and cannot be reached through remote attacks.

In practice, many organizations use online intermediate CAs to issue certificates for users, devices, applications, and network services. If an intermediate CA is ever compromised, the damage is much easier to contain. The offline root CA can revoke the compromised intermediate, issue a replacement, and restore trust without requiring every endpoint to install a new root certificate.

For organizations deploying certificate-based authentication for Wi-Fi, VPNs, or other enterprise services, an offline root CA is more than a traditional PKI design choice. It provides the resilience needed to recover from a CA compromise while maintaining the trusted identities that Zero Trust architectures rely on.

Learn more about PKI and certificate management in the video below:

SecureW2: Simple PKI Certificate Management for You

SecureW2 offers an end-to-end public key infrastructure service that significantly simplifies the management of certificate authorities, making it easier for organizations to deploy and maintain a robust security framework.

With capabilities that include automated certificate issuance and renewal, SecureW2 keeps the chain of trust unbroken and secure across all user devices and applications.

This managed service significantly reduces the traditional complexities of certificate management, such as manual certificate signing requests (CSRs), enrollment, and installation, reducing misconfigured certificates and vulnerabilities.

Our cloud-based PKI solution, JoinNow Dynamic PKI, integrates seamlessly with existing directories, does not require any hardware, and offers a user-friendly experience that simplifies generating root and intermediate CAs. This ease of use makes it ideal for organizations of any size looking to bolster their security posture.

By leveraging Dynamic PKI, organizations can manage their root and intermediate certificate authorities efficiently. Schedule a demo to check it out today.

---

Frequently Asked Questions

What happens if an intermediate CA is compromised?

If an intermediate CA is compromised, the issuing organization can revoke the intermediate certificate and replace it without affecting the trusted root CA. This containment is one of the primary reasons PKI architectures use intermediate CAs, as it limits the scope of security incidents and avoids disrupting every certificate in the trust hierarchy.

Can an organization create its own root and intermediate certificate authorities?

Yes. Organizations can operate a private PKI by creating their own root and intermediate CAs to issue certificates for employees, devices, applications, and network infrastructure. This approach provides greater control over authentication policies but also requires secure key management, certificate lifecycle management, and ongoing maintenance.

Why don't root CAs issue certificates directly to users and devices?

Root CAs rarely issue end-entity certificates directly because doing so would expose their highly sensitive private keys to unnecessary risk. Instead, root CAs delegate certificate issuance to intermediate CAs, keeping the root key secure while maintaining the integrity of the certificate chain of trust.

How does certificate authentication improve security compared to passwords?

Unlike passwords, certificates rely on cryptographic key pairs that cannot be guessed, reused, or stolen through common phishing attacks. When used with protocols like EAP-TLS and 802.1X, certificate-based authentication can verify both users and devices while reducing the risk of credential theft and unauthorized network access.

How do organizations manage root and intermediate certificates at scale?

Many organizations use a managed PKI solution to automate certificate issuance, renewal, revocation, and policy enforcement. Automated certificate lifecycle management helps prevent outages caused by expired certificates, reduces administrative overhead, and ensures root and intermediate CAs remain properly maintained as environments grow.