# Root and intermediate certificate authorities

A root CA is a self-signed certificate that lives in your operating system's trust store and acts as a trust anchor. An intermediate CA is signed by the root and does the day-to-day work of issuing certificates. The split exists so the root's private key can stay offline: if an intermediate is compromised it can be revoked and replaced without every operating system and browser on earth needing an update. Servers must send their intermediates and must not send the root, because clients that trust the root already have it.

Source: https://certguru.io/concepts/root-vs-intermediate-ca/
Last updated: 2026-08-19
Commands verified against OpenSSL 3.5.7.

---

## The hierarchy

```text
Root CA                    self-signed, in your trust store, key kept offline
  |
  +-- Intermediate CA       signed by the root, key online, does the issuing
        |
        +-- example.com     the certificate your server presents
```

## Telling them apart

*A root signs itself*

```bash
openssl x509 -in root-ca.crt -noout -subject -issuer
```

Expected output:

```
subject=C = US, O = Example CA, CN = Example Root CA
issuer=C = US, O = Example CA, CN = Example Root CA
```

*An intermediate names its parent*

```bash
openssl x509 -in intermediate.crt -noout -subject -issuer
```

Expected output:

```
subject=C = US, O = Example CA, CN = Example Intermediate CA
issuer=C = US, O = Example CA, CN = Example Root CA
```

Both have `CA:TRUE`, so that alone does not tell you which is which:

```bash
openssl x509 -in intermediate.crt -noout -ext basicConstraints
```

Expected output:

```
X509v3 Basic Constraints: critical
    CA:TRUE, pathlen:0
```

`pathlen:0` is worth noticing — it means this CA may issue end-entity certificates but may not
create further CAs beneath it.

## Why the split exists

A root private key is the most valuable object in the system. Anyone holding it can issue a
certificate for any hostname on the internet, and every browser will accept it. So roots are
generated in a ceremony, stored in hardware security modules, and kept physically offline.

If roots signed server certificates directly, that key would have to be online and used thousands of
times a day. Instead the root signs a handful of intermediates once, and the intermediates take the
operational risk.

The consequence that matters: **a compromised intermediate can be revoked.** Browsers and operating
systems distribute revocation for intermediates routinely. A compromised *root* cannot be handled
that way — it would require an update to every device, and devices that no longer receive updates
would be stranded.

## What the server sends

| Certificate | Server sends it? | Why |
| --- | --- | --- |
| Leaf (yours) | **Yes** | It is the identity being presented |
| Intermediate | **Yes** | The client has no other way to get it |
| Root | **No** | Trusting clients have it; others gain nothing |

```bash
cat certificate.crt intermediate.crt > fullchain.crt
```

Omitting the intermediate is the most common TLS misconfiguration there is — see
[unable to get local issuer certificate](/errors/unable-to-get-local-issuer-certificate/).

## Cross-signing

An intermediate is sometimes signed by more than one root, so that older devices which only trust an
old root and newer devices which trust a new one both build a valid path. This is how a new CA
bootstraps trust on devices that will never receive a software update.

The practical consequence is that one certificate may have more than one valid chain, and different
clients may build different ones. A chain that validates on your laptop can still fail on an old
Android device.

## Running your own

The same structure works for an internal PKI, and for a small one the extra layer is often not worth
it — signing directly from the root is simpler and the offline-root benefit only materialises if you
actually keep it offline.

- [Create a root CA](/openssl/create-root-ca/)
- [Create an intermediate CA](/openssl/create-intermediate-ca/)
- [Sign a CSR](/openssl/sign-csr-with-ca/)


## Frequently asked questions

### How do I tell a root from an intermediate?

Compare subject and issuer. A root's are identical — it signed itself. An intermediate's issuer names the certificate above it. Both carry `basicConstraints CA:TRUE`, so that field does not distinguish them.

### Why does my server need to send the intermediate?

Because clients only have roots. Without the intermediate, the client cannot connect your certificate to any root it trusts, and verification stops with error 20.

### Should the root be in my server's chain file?

No. Clients that trust it already have it, so sending it wastes bandwidth on every handshake. Clients that do not trust it gain nothing from receiving it.

### What happens when a root expires?

Everything under it stops validating, which is why roots are issued with 20-year-plus lifetimes and replacements are distributed years ahead. The Let's Encrypt DST Root CA X3 expiry in 2021 broke a large number of older devices for exactly this reason.


## References

- [RFC 5280: X.509 and CRL profile](https://www.rfc-editor.org/rfc/rfc5280) — the specification every field on a certificate comes from
- [Mozilla CA certificate policy](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/) — the rules behind what reaches a browser trust store

## Related pages

- https://certguru.io/concepts/certificate-chain/
- https://certguru.io/openssl/create-root-ca/
- https://certguru.io/openssl/create-intermediate-ca/
- https://certguru.io/errors/unable-to-get-local-issuer-certificate/
- https://certguru.io/concepts/self-signed-vs-ca-signed/
- https://certguru.io/concepts/free-tls-certificate/

--
CertGuru — https://certguru.io