Root vs Intermediate Certificate Authority Guide

One of the main problems in online communication is trust. Let’s say you communicate with your bank through its website: how can you be sure the bank’s page is real and that a third party is not imitating it and attempting to steal your data?

Your device and the bank’s page need to establish trust. Trust depends on having a reliable way to confirm that an entity is who it claims to be. So, when communicating over the internet, entities can use certificates as their identities.

This article will simplify certificates by covering the basics of root vs. intermediate certificates, certificate authorities (CAs), and why SSL/TLS certificates are widely used for internet browsing.

What Is a Digital Certificate?

A digital certificate is a secure method of guaranteeing the identity of entities that communicate online. Defined in internet standard X.509, digital certificates use advanced and secure cryptography to provide an efficient way to work with users’ identities. This complex cryptography ensures that users are protected from outside threats when online.

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.

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.

Let’s consider how the architecture of a web application works. It typically consists of a server that hosts the application, the backend services that power its functionality, and a database, along with 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 is also reflected in the way 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 to create a trusted environment where data can be securely exchanged. They form the backbone of secure online communication, ensuring users can confidently navigate the web, engage in e-commerce, and exchange information without fear of interception or fraud. Through a rigorous validation process, CAs maintain the integrity and trustworthiness of the internet.

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. Trusted root certificates are pre-installed in major browsers and operating systems’ trust stores (also known as root stores), making them inherently trusted by devices worldwide.

Historically, their validity is long-lasting; root certificates may last 20-30 years. But as of 2026, the standard cap is 200 days or less and is set to reduce to 47 days in 2029.

The trust model of root certificate authorities relies on the inherent trust placed in them by software manufacturers, application developers, and end-users. Many hardware and software manufacturers establish their own root programs to determine which CAs to include in their trusted CA store. For example, Microsoft has its own root store, along with Google and Apple root stores.

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. This root certificate’s private key must be guarded with the highest level of security, as its compromise could undermine the trust model of literally every certificate issued under its hierarchy.

Despite their critical role, root certificate authorities are not without their limitations and vulnerabilities. The security of 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 trust stores of major browsers and operating systems, any certificate chain that links back to these root CAs is considered valid.

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 begins issuing certificates, every device trusting that root CA will accept those security certificates — despite potentially dangerous consequences. That’s why root CA security controls are necessarily 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 act under the authority of root certificate authorities but take on the day-to-day responsibilities of validating and issuing certificates to end entities. After performing the required checks and validations, they function by issuing certificates to entities or individuals.

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

Unlike root certificate authorities, intermediate CAs can more freely distribute and do less risk to the overarching trust model if compromised due to their position in the certificate chain of trust being one step removed from the root certificate and CA itself.

How Do Intermediate Certificates Extend Trust?

Intermediate CAs extend this trust by issuing certificates to end entities while being directly linked to a root CA. This extension allows for a more flexible and secure distribution of certificates. It also enables root CAs to keep their keys more secure by not using them frequently, which reduces 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. But intermediate certificates live in the middle, mitigating security risks and fraud with more frequent trust verification.

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

Benefits of Using Intermediate CAs

Using intermediate CAs offers several advantages. They reduce the risk to root CAs by acting as a buffer. If an intermediate CA is compromised, its certificate can be revoked without affecting the root certificate authorities or other intermediate certificate authorities. This structure also allows for more flexible management and distribution of certificates, enabling businesses and organizations to issue their 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. While root CAs provide the ultimate source of trust, intermediate CAs extend the reach of this trust by issuing certificates down the certificate chain. This structure allows for scalability in issuing certificates, with the root CA only needing 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 one operated by an intermediate certificate authority without 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 utilizing 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 must 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 very specific order in what is known as 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 given certificate is legitimate and can be traced back to a root CA that is widely recognized and trusted.

CAs build the certificate chains by issuing certificates signed with their private key. When a certificate is verified, the digital signature is checked against the public key of the issuing CA. If it matches, the process continues 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.

Differences Between Root and Intermediate CAs

Now let’s look at the difference between root and intermediate CAs:

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 intermediate certificates to end entities like 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.

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 the automation of certificate issuance and renewal processes, SecureW2 ensures that the chain of trust remains unbroken and secure across all user devices and applications.

This managed service eliminates the traditional complexities associated with certificate management, such as manual certificate signing requests (CSRs), enrollment, and installation, thereby reducing the incidence of 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 the process of 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 ensure that their root and intermediate certificate authorities are managed efficiently, aligning perfectly with this article’s focus on creating a trustworthy and secure internet environment. 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, allowing the root key to remain securely protected 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.