SSL Chain of Trust: How Intermediate CAs Work

⏱️ Reading time: 14 min

In 2026 the NVD catalogued CVE-2026-111943, a case that once again puts the spotlight on the intermediate certificate authority, the piece that holds up the SSL chain of trust for thousands of sites. When that link gets compromised, the problem scales to every certificate that intermediate signed, all at once.

📑 En este artículo

1. TL;DR
2. What is the SSL chain of trust?
3. Why it matters when an intermediate CA gets compromised
4. How the certificate authority hierarchy is built
5. Practical examples: inspecting a certificate chain with OpenSSL
6. Getting started: verifying a certificate chain from your terminal
7. Real-world use cases of the certificate authority hierarchy
8. Common mistakes when configuring a certificate chain
9. Comparison: how a certificate is revoked or verified
10. Going deeper: path validation and the limits of trust in the certificate authority hierarchy
11. Frequently Asked Questions
    1. What’s the difference between a root CA and an intermediate CA?
    2. How is the SSL chain of trust verified in a browser?
    3. What happens if an intermediate CA is revoked?
    4. Does a self-signed certificate have a certificate chain?
    5. Why don’t browsers trust Let’s Encrypt directly?
    6. Does Certificate Transparency replace OCSP revocation?
12. References

To understand what it actually means for a CA to be compromised, you have to take that chain apart: who signs whom, what the browser validates on each connection, and what happens when a certificate needs to be revoked in the middle of the hierarchy.

TL;DR

• An intermediate CA signs on behalf of a root that the browser already ships with out of the box.
• OCSP and CRLs flag that a certificate was revoked before it expires on its own.
• openssl s_client -showcerts shows the full chain a server sends, from the leaf to the root.
• Certificate Transparency logs every certificate publicly, so a malicious intermediate doesn’t go unnoticed.
• Compromising a single intermediate instantly invalidates every certificate that authority signed.

What is the SSL chain of trust?

The SSL chain of trust is the sequence of digital signatures that connects a website’s certificate to a root authority already installed in the operating system or browser, passing through one or more intermediate certificate authorities that delegate that trust without exposing the root key.

The root almost never signs site certificates directly: its private key is kept offline, often under multiple custodians, because if it leaks it has to be replaced on every operating system on the planet. That’s why intermediates exist, signing on behalf of the root; if one gets compromised, it’s enough to revoke that intermediate without touching the root.

Every certificate in the chain includes an Issuer field (who signed it) and a Subject field (who it belongs to). The browser follows that chain from Issuer to Issuer until it hits a Subject already present in its trust store. This whole mechanism of roots, intermediates, and leaves is known as public key infrastructure, or PKI.

Why it matters when an intermediate CA gets compromised

A compromised intermediate affects, all at once, every site that authority signed, which can be thousands or millions depending on the CA’s size. An attacker holding an intermediate’s private key can issue valid certificates for any domain, including banks, email, or critical infrastructure, without the browser noticing anything wrong, because the signature is mathematically correct.

With a valid fraudulent certificate, an attacker on a public wifi network or with control over network infrastructure can insert themselves between the user and the real site, an attack known as machine-in-the-middle, without triggering any warning. The padlock still shows green, because the certificate chain the browser receives is, technically, valid.

The historical case that best illustrates the risk is DigiNotar, a Dutch CA compromised in 2011: the attacker issued fraudulent certificates for Google domains, and browsers ended up completely pulling trust from that authority. The company went bankrupt months later.

The ones who decide which roots deserve that level of trust are the so-called root programs: Mozilla, Chrome’s root program, and Apple’s publish their own criteria and audit each CA with annual WebTrust or ETSI reports. A compromised intermediate that isn’t handled transparently, without reporting the incident or revoking in time, can cost the entire CA its place in those stores, not just the affected intermediate.

That’s why the response to a compromised intermediate isn’t patching the certificate: it’s revoking it, and in the most serious cases, removing the entire root from the trust stores of Chrome, Firefox, and the operating systems. That instantly invalidates every certificate issued under that hierarchy, even the ones that had nothing to do with the attack.

How the certificate authority hierarchy is built

The hierarchy always has at least three levels: the root CA, one or more intermediates, and the leaf certificate your browser receives when you visit a site. Some large CAs, like Let’s Encrypt, run several intermediates in parallel to spread the risk and make rotation easier.

When your browser connects to a server over HTTPS, the server sends its leaf certificate along with the chain of intermediates needed to complete the path to a trusted root. The browser doesn’t just trust whatever the server declares. It rebuilds the full path, verifying each signature with the public key of the previous link, until it reaches a root it already has stored.

The root’s private key almost always lives inside a hardware security module (HSM) kept in a vault, and signing something with it is a ceremonial event that requires several people present, cameras recording, and a written step-by-step script. That’s why roots barely sign anything directly except, every so often, a new intermediate. All the day-to-day work of issuing certificates falls to the intermediates, which run on online infrastructure and are therefore also the most likely target for an attacker.

That process of building and validating the path is called path building and is formalized in RFC 5280, which defines how to validate X.509 certificates: validity dates, critical extensions, maximum chain length (basicConstraints), and what to do when there are multiple possible paths to a trusted root.

flowchart TD
    A["Root authority (in the OS trust store)"] --> B["Intermediate CA signs with its private key"]
    B --> C["Website's leaf certificate"]
    C --> D["Browser rebuilds and validates the chain"]

Practical examples: inspecting a certificate chain with OpenSSL

The most direct way to see this in action is from the terminal. The following command connects to a real site over TLS and shows the subject and issuer of every certificate the server sends:

echo | openssl s_client -connect www.google.com:443 -showcerts 2>/dev/null | openssl x509 -noout -subject -issuer

The output always follows this pattern, although the specific names of the current CA change over time:

subject=CN = www.google.com
issuer=C = US, O = Google Trust Services, CN = WR2

The issuer field of that leaf certificate is, precisely, the subject of the intermediate CA that signed it. If you chain that lookup, requesting the certificate whose subject matches that issuer, and keep going link by link up to the root, you’re doing exactly what the browser does internally.

To also see the validity dates and where to check revocation status:

echo | openssl s_client -connect www.google.com:443 -showcerts 2>/dev/null | openssl x509 -noout -dates -ext authorityInfoAccess

That shows the validity range (notBefore and notAfter) and the OCSP responder URL the certificate declares, the same one your browser queries to check if it’s still valid (the specific values vary by issuing CA):

notBefore=Jan 10 08:00:00 2026 GMT
notAfter=Apr 10 08:00:00 2026 GMT
Authority Information Access:
    OCSP - URI:http://ocsp.pki.goog/gts1c3

To validate the full chain against the system’s trust store, without checking field by field, use:

openssl s_client -connect www.google.com:443 -verify_return_error </dev/null

If everything checks out, among the last lines you’ll see:

Verify return code: 0 (ok)

A code other than 0 (for example 21 or 2) points to a specific problem in the chain: expired certificate, unknown issuer, or missing intermediate. That is, in practice, how you confirm a certificate chain is valid without relying solely on the browser’s padlock icon.

Getting started: verifying a certificate chain from your terminal

The only dependency is having OpenSSL installed. It ships preinstalled on macOS and on nearly every Linux distribution; on Windows, the simplest option is Git Bash or WSL, which include it out of the box.

First, confirm the installed version:

openssl version

Expected output (the exact number depends on your system):

OpenSSL 3.0.13 30 Jan 2024

Next, download a site’s full chain to a file so you can inspect it at your own pace:

echo | openssl s_client -connect www.google.com:443 -showcerts 2>/dev/null > chain.txt

Open chain.txt and you’ll see several -----BEGIN CERTIFICATE----- blocks: the first is the leaf, the rest are the intermediates the server chose to send. Count them: if it’s your own server and only one block shows up, the intermediate is missing, which is the most common incomplete-chain error in production.

Real-world use cases of the certificate authority hierarchy

Let’s Encrypt has issued free certificates since 2015, doing so exclusively through intermediates, with ISRG Root X1 as the root and several intermediates rotating underneath it. It never signs a site certificate directly with the root, the same isolation pattern that separates day-to-day risk from the key that, if lost, would force a rebuild of trust across the entire internet.

Automating renewal is part of the design: the ACME protocol Let’s Encrypt uses, which other CAs have also adopted, lets you renew a certificate with a command like certbot renew, with no human intervention, because its certificates only last 90 days. A short validity window shrinks the damage from a wrongly issued certificate, since it expires within weeks instead of the one or two years that used to be common.

Banks and critical infrastructure typically require, on top of the standard chain, Certificate Transparency: a public, immutable record of every certificate issued by any recognized CA. If a compromised intermediate issues a fake certificate for a domain, that certificate gets logged in CT, and monitoring tools, including ones Google and Cloudflare offer for free, can flag it within minutes even if the attack never touched that infrastructure.

Common mistakes when configuring a certificate chain

• Incomplete chain: the server sends only the leaf certificate and forgets the intermediates; it works in browsers that cache known intermediates and fails in mobile apps or curl.
• Wrong order: some older servers expect the chain in a specific order, and reversing it breaks validation on strict TLS clients.
• OCSP soft-fail: if the revocation responder doesn’t answer in time, most browsers let the connection through instead of blocking it, by design, so the internet doesn’t break every time a responder goes down.
• Clock out of sync: a certificate flagged as not yet valid or expired is almost always a system clock issue, not the certificate itself.
• Confusing expiration with revocation: an expired certificate simply ran past its date; a revoked one was invalidated early by the CA, and browsers treat the two cases differently without always making that clear in the error message.

⚠️ Heads up: OCSP soft-fail means that, in practice, revoking a certificate doesn’t guarantee blocking the attacker right away, because many clients will still accept it if they can’t check the revocation status in time.

Comparison: how a certificate is revoked or verified

None of these mechanisms compete with each other: in practice they combine, and understanding when each one kicks in helps diagnose why a browser blocks, or doesn’t block, a suspicious connection.

Going deeper: path validation and the limits of trust in the certificate authority hierarchy

The algorithm the browser runs on every connection is called certification path validation and is described in detail in RFC 5280. It doesn’t just verify signatures: it also checks that every intermediate CA has the basicConstraints: CA=TRUE bit set, that the maximum chain depth (pathLenConstraint) hasn’t been exceeded, and that no certificate in the path is marked as revoked.

Two key fields tie one link to the next: the Subject Key Identifier (SKI) of the signing CA, and the Authority Key Identifier (AKI) of the signed certificate, which must point exactly to that SKI. When a root renews with a new key, old intermediates stop chaining until someone re-signs them under that new key, a process called cross-signing that large CAs use to avoid breaking compatibility all at once.

A real example of cross-signing: for years, Let’s Encrypt also signed its ISRG Root X1 root under an older root, DST Root CA X3, so that outdated Android devices, which didn’t have the new root installed, could still validate the chain. When that old root expired, some unsupported devices were left with no way to trust those certificates. Simplifying the chain carries that cost: sometimes it leaves behind whoever hasn’t updated.

Recent versions of Chrome and Safari now require, on top of a valid chain, that every certificate carry a Signed Certificate Timestamp (SCT) from at least two different Certificate Transparency logs. Without that, the browser treats the connection as untrusted even if the signature is technically correct: it’s the layer that closes the gap a compromised intermediate would otherwise leave by issuing silently.

sequenceDiagram
    participant N as Browser
    participant S as Server
    participant O as OCSP Responder
    N->>S: starts the TLS handshake
    S-->>N: sends leaf and intermediate certificate
    N->>N: builds the chain up to the trusted root
    N->>O: queries revocation status
    O-->>N: responds valid or revoked
    Note over N,S: if the chain or OCSP fails, the browser aborts the connection

Your next step: run openssl s_client -connect your-domain.com:443 -showcerts against a site you own and count how many certificates it returns before assuming the chain is complete.

Frequently Asked Questions

What’s the difference between a root CA and an intermediate CA?

The root is the authority browsers and operating systems trust out of the box, with its private key kept offline. The intermediate is an authority the root signed so it can issue day-to-day certificates, delegating trust without exposing the root key.

How is the SSL chain of trust verified in a browser?

The browser rebuilds the path from the site’s certificate, verifying each signature with the public key of the previous link, until it reaches a root already in its trust store. If it can’t complete the path, it shows an untrusted certificate warning.

What happens if an intermediate CA is revoked?

Every certificate that intermediate signed immediately stops being valid, even if individually they had no issues at all. That’s why large CAs spread issuance across several intermediates: if one goes down, the damage is limited to its share of the traffic.

Does a self-signed certificate have a certificate chain?

No: a self-signed certificate is its own issuer and its own subject, with no intermediate link or external root backing it. That’s why the browser marks it as untrusted unless you’ve manually added it to the local store.

Why don’t browsers trust Let’s Encrypt directly?

They do trust it, but through its hierarchy: the ISRG Root X1 root has been in trust stores for years, and Let’s Encrypt signs every certificate with an intermediate hanging off that root, never with the root itself.

Does Certificate Transparency replace OCSP revocation?

No, they’re complementary: CT publicly exposes that a certificate exists, but doesn’t say whether it’s revoked. OCSP and OCSP stapling are what communicate revocation status in real time.

References

• NVD, CVE-2026-111943: official record of the vulnerability that prompted this article.
• RFC 5280 (IETF): specification for X.509 certificates and trust path validation.
• Let’s Encrypt, How It Works: how a free CA issues certificates through intermediates.
• Wikipedia, DigiNotar: the historical case of an intermediate CA compromised in 2011.
• MDN, Transport Layer Security: reference documentation on TLS and certificates.

📱 Like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day. @programacion

Featured image: Foto de FlyD en Unsplash