Infosec Journey

I wanted to give an overview of Public Key Infrastructure (PKI) with maximum abstraction — keeping the explanation simple and accessible — without losing the core integrity and technical correctness of how trust and certificate hierarchies truly work. This blog aims to demystify the essential concepts for readers new to PKI while preserving the critical security principles that underpin digital trust online.

When a user accesses an application, there must be trust that the application they reach is truly the legitimate one it claims to be. Especially when encountering new or unfamiliar sites, simple technical checks can help avoid falling victim to scams.

Let’s consider an application, myapp.example.com, accessed by users across various locations. How can users be sure they are really connecting to myapp.example.com? Public Key Infrastructure (PKI) is the system that enables this trust.

What Is a Certificate?
A certificate is a digital document that publicly claims who an entity is, accompanied by a cryptographic public key. It is like a digital passport confirming the server’s identity. Sometimes, a single certificate is used per application and trusted manually by end users (called a self-signed certificate). While that can work technically, it’s inadequate for real-world security because it lacks external validation and scalable trust.

For example, if myapp.example.com were a scam site using one single self-signed certificate, a user has no independent assurance of authenticity and risks being misled. Checking the certificate’s chain via a browser or operating system can help: Does the certificate stand alone, or is it backed by a trusted authority?

How Is Trust Established in PKI?
Trust comes from a set of recognized Certificate Authorities (CAs) — organizations like Google, Microsoft, Apple, and others — whose root CA certificates are pre-installed and trusted on most operating systems and browsers. These root certificates attest to the legitimacy of other certificates in a hierarchical fashion.

This hierarchy commonly follows either:

• Three-layer (hierarchical) chain: Root CA → Intermediate CA → Issuing CA → Server (leaf) certificate
• Two-layer chain: Root CA → Issuing CA → Server (leaf) certificate

The self-signed certificate scenario has no such layering and carries significant security risks.

What Happens in These Layers?

More layers mean increased security, separation of duties, and damage containment if compromise occurs.

• The Root CA is the ultimate trust anchor — its private key is kept offline and highly secured.
• The Intermediate CA (sometimes called policy or subordinate CA) is signed by the root and delegates authority, often enforcing policies and administrative boundaries. Its private key is usually kept offline or in a highly secure environment.
• The Issuing CA signs server or user certificates; it is typically online but carefully protected, often using hardware security modules (HSMs).
• The Server (leaf) certificate is what users see for myapp.example.com; its private key is stored securely on the hosting server.

CSRs and Certificate Signing in a Three-Layer PKI Hierarchy

Here is how the Certificate Signing Requests (CSRs) and certificate signing flow work in the three-layer hierarchy:

• The Root CA is self-signed, meaning it creates and signs its own certificate. This root private key is kept offline in a secure environment to protect it from compromise.
• The Intermediate CA generates its own key pair (private/public) and creates a CSR for its certificate. This CSR is sent to the Root CA to be signed. Once signed, the Intermediate CA certificate is issued. The Intermediate CA’s private key remains offline or in a secure environment according to the setup.
• The Issuing CA generates its own key pair and creates a CSR, which it sends to the Intermediate CA. The Intermediate CA signs this CSR and issues the Issuing CA certificate. The Issuing CA’s private key is kept secure and online, often protected within an HSM.
• The Server administrator creates a key pair for the server (e.g., myapp.example.com) and generates a CSR. This CSR is sent to the Issuing CA, which verifies and signs it to issue the server’s certificate. The server private key is kept securely on the server and not transmitted elsewhere.

This delegation and signing flow establishes a chain of trust from the Root CA down to the server certificate. This chain is verified by client browsers during SSL/TLS connections.

Private Keys and Their Security

Every certificate uses a public-private key pair:

• The private key is secret and must be tightly protected by its owner.
• The public key is included in the certificate and freely shared with clients to verify identity.

In a single-layer self-signed certificate, if the private key is compromised, the entire certificate loses trust, and all clients must manually replace and trust a new certificate — an error-prone, disruptive process.

In a multi-layer hierarchy, if a private key at any CA level is compromised, the impact is mitigated because:

• The root private key is offline and used only to sign intermediate CA certs, reducing compromise risk.
• Compromise of an intermediate or issuing CA affects only certificates beneath that CA, limiting revocation scope and disruption.
• Server key compromise needs immediate revocation and re-issuance but does not require rebuilding the entire PKI.

How Trust Works

Imagine Google as the Root CA:

• Google’s Root CA signs an Intermediate CA certificate.
• The Intermediate CA signs the Issuing CA certificate (or directly signs the server certificate in smaller hierarchies).
• The Issuing CA signs the server (leaf) certificate used by myapp.example.com.
• When a user visits myapp.example.com, their browser receives the server certificate along with intermediate and issuing CA certificates (the certificate chain).
• The browser trusts the Root CA (installed in its trusted root store) and verifies the entire chain up to the leaf certificate.
• This layered trust lets the user securely connect without manual trust overrides.

What About the SSL/TLS Handshake?

During the SSL/TLS handshake:

• The server presents the server (leaf) certificate and the certificate chain (intermediate and issuing CA certs). The root certificate is usually not sent because the client already trusts it.
• The client validates the signatures on each certificate in the chain, verifies the domain name matches, checks expiration, and queries revocation status (via CRL or OCSP).
• If all checks pass, the client and server establish a secure encrypted session.

In PKI, layering isn’t complexity—it’s your strongest defense against digital threats.