Certificate Authority Hierarchy: How It Works

Android recently issued a list of root certificates that it has added to Android 14. While this move isn't altogether surprising, it’s interesting to note that some root certificates have also been removed from the approved list. These include those from household names in the certificate authority (CA) space, such as VeriSign Universal Root Certification Authority and Chambers of Commerce Root.

Why did Android make this shift? Most likely because of the increasing number of malicious certificate authorities issuing fraudulent certificates. A fake certificate authority compromises your security, enabling the criminal who issued it to steal data in transit. But with a sound certificate issuance process, you can rest assured that your certificates are legitimate.

While Android 14 users can breathe a sigh of relief, thanks to the system's approved certificate list, others face a difficult question: How do I know where my certificate came from? Is it legit?

The answers are simple once you understand the certificate authority hierarchy. Here’s a breakdown of what this is, how it works, and the links in the chain.

Understanding CA Hierarchy and Trust Chains

Whether you’re using Transport Layer Security (TLS) or Secure Sockets Layer (SSL) security, the CA hierarchy defines the relationships between CAs and end users. The hierarchy is relatively simple, and you can think of it as a tree.

First, you have the root certificates, of which there are relatively few. These provide certificates to intermediate CAs, who then issue them to end entities or end users.

The paths the certificates follow as they move from one entity to another are called trust chains. Every time a site, device, or application presents a certificate, the recipient’s system checks the validity of the trust chain. If the recipient’s system detects an illegitimate entity in the chain, it rejects the certificate and stops the communication or data transfer.

Because the roles and responsibilities of each party differ, here’s an explanation of what’s involved at each phase of the hierarchy.

Root Certificates

A certificate authority issues and signs root certificates. Examples of trusted CAs that serve as the primary issuers of certificates are Sectigo, Entrust, DigiCert, and QuoVadis.

To use the popular passport illustration, if certificates are like passports, then root certificate issuers would be the equivalent of the United States government or another country. They’re in charge of making sure each certificate is legitimate, as well as maintaining the integrity of their internal systems. A valid internal system is crucial—root CAs must diligently verify the legitimacy of the parties to whom they grant certificates.

Intermediate Certificates

Intermediate certificates come from intermediate certificate authorities. These are those the root CAs authorize to issue certificates on their behalf. Intermediate CAs serve a few purposes, each of which helps establish trust and efficiency in the trust chain:

• They add an element of decentralization to the trust chain because they assume a role similar to that of root CAs.

• Intermediate CAs enable a scalable certificate system because they can act as intermediaries between root CAs and end entities. By simply adding a new, trusted intermediate CA, a root CA can expand its ability to issue certificates.
• They add an extra layer of trust because they have to verify the legitimacy of each certificate the root CA allows them to issue. This creates a more secure system.

End-Entity Certificates

End-entity certificates are also referred to as “leaf” certificates because they’re at the other end of the tree—on the opposite side of the root. End-entity certificates have two essential components:

• The public key the end entity uses to initiate communications

• The root CA's digital signature that verifies the certificate’s authenticity

Devices, sites, and applications use the end-entity certificate to establish secure connections. When the end entity presents its certificate, the recipient checks the trust chain associated with the certificate to make sure it’s valid.

For example, if the trust chain analysis reveals an illegitimate certificate issuer, the recipient will block communication between itself and the end entity. Stopping this interaction is an important security step. For instance, preventing the digital handshake from happening could prevent a hacker from presenting a malware-infected application or fake website.

Efficiently Manage Your Certificate Hierarchies

The certificate hierarchy provides users with reliable certificates that enable secure, encrypted communications with trusted parties. The root certificate authority provides the original certificate and then issues it to an intermediate certificate authority. The intermediate CA then has the power to issue the certificate to end entities.

Sectigo is a trusted commercial CA that provides comprehensive certificate management, so you never have to question where your certificates come from or worry about them expiring without notice. Contact Sectigo today to learn more.