Cybersecurity glossary
What is an Intermediate Certificate?
Learn what an intermediate certificate is, how issuing CAs delegate trust from offline roots, why chain installation matters, and how pathLen constraints limit subordinate CAs.
Definition
An intermediate certificate is an X.509 CA certificate signed by a root CA or another intermediate CA that is authorized to issue certificates below it, usually leaf TLS certificates, while keeping the root key protected and offline.
Why intermediate certificates exist
An intermediate certificate is the working CA certificate in most TLS deployments. It gives a certificate authority a controlled way to issue leaf certificates while protecting the root CA key that anchors trust.
Root certificates are difficult to replace because browsers, operating systems, runtimes, appliances, and private trust stores distribute them widely. Keeping root keys offline reduces the chance that a single online system compromise becomes a root-level PKI disaster.
The issuing CA role
Intermediate certificates usually act as issuing CAs. They sign certificates below them, apply CA policy, publish revocation information, and separate different issuance programs such as public TLS, private PKI, device identity, client authentication, or code signing.
Delegated trust
A root or higher CA signs the intermediate, giving it limited authority under a defined certificate policy.
Day-to-day issuance
The intermediate signs leaf certificates for domains, APIs, workloads, users, or devices.
Root protection
The root private key can stay offline while online CA infrastructure handles routine issuance and renewal.
Scoped recovery
A compromised or misbehaving intermediate can be revoked and replaced with less disruption than replacing a root.
How an intermediate fits into a TLS chain
During a TLS handshake, the server presents its leaf certificate and the intermediate certificates needed to build a path to a trusted root. The client validates signatures and constraints from the leaf upward, then anchors the path in a root certificate it already trusts.
Root signs an intermediate
The root CA certifies the intermediate CA public key and encodes constraints such as CA=true, keyCertSign, and pathLen.
Intermediate signs the leaf
The issuing CA signs the service certificate after validation and policy checks.
Server installs the chain
The TLS endpoint deploys the leaf certificate followed by the required intermediate certificates.
Client builds a path
The relying party links the leaf to the intermediate and then to a trusted root from its trust store.
Client enforces constraints
Validation checks signatures, validity dates, Key Usage, Basic Constraints, name rules, revocation, and pathLen limits.
Chain installation details that break real systems
Installing an intermediate certificate is operationally simple but easy to get wrong. A server should present the leaf certificate first, then each intermediate needed to reach the root. It usually should not include the root certificate because the client must already trust the root locally.
| Mistake | Impact | Fix |
|---|---|---|
| Missing intermediate | Some clients cannot build a valid path and reject the certificate. | Install the CA bundle provided with the leaf certificate. |
| Wrong intermediate | Path building may terminate at an untrusted, expired, or distrusted root. | Match the issuer and Authority Key Identifier for the deployed leaf. |
| Incorrect order | Modern clients often recover, but older clients and appliances may fail. | Serve leaf first, then intermediates in issuer order. |
| Root included as trust proof | The extra certificate does not create trust and can confuse brittle tooling. | Send only the leaf and required intermediates unless a platform explicitly requires otherwise. |
pathLen constraints and subordinate CA control
The X.509 Basic Constraints extension marks whether a certificate is allowed to act as a CA. When the CA flag is true, a pathLen constraint can limit how many additional CA certificates may appear below that certificate in a valid chain.
For example, an intermediate with pathLen=0 can issue leaf certificates but cannot validly create another subordinate CA beneath it. An intermediate with pathLen=1 may allow one more CA layer below it, depending on the rest of the certificate policy and extension checks. Clients enforce this during path validation, so violating the constraint breaks the chain even when signatures are mathematically correct.
Operational checklist
- Keep root CA private keys offline or in tightly controlled ceremonies whenever possible.
- Use intermediates for routine issuance and scope each one by policy, key usage, EKU, name constraints, and pathLen.
- Install the full server chain: leaf certificate first, then every required intermediate.
- Do not rely on clients fetching missing intermediates through Authority Information Access.
- Monitor expiration and revocation status for intermediates, not only leaf certificates.
- Test deployed chains from browsers, mobile devices, Java runtimes, containers, scanners, and appliances that matter to your environment.
- Replace intermediates deliberately after CA policy changes, algorithm deprecation, compromise, or root program distrust events.
The practical takeaway
An Intermediate Certificate is the controlled bridge between a trusted root and the leaf certificates used by services. It lets CAs keep root keys offline, delegate issuing authority, constrain subordinate CAs with Basic Constraints and pathLen, and recover from operational problems without replacing every trust anchor.
For TLS operators, the main job is to install the right chain and monitor it as infrastructure. A valid leaf certificate still fails when the intermediate is missing, mismatched, expired, revoked, or allowed to issue only under constraints the presented path violates.
Related security terms
Root Certificate
The trust anchor that commonly signs intermediate CA certificates while keeping its private key highly protected.
Certificate Chain
The ordered path from a leaf certificate through intermediates to a trusted root.
Certificate Authority (CA)
The organization or service that validates subjects and signs certificates under defined policy.
Trust Anchor
A certificate or key a relying party already trusts as the endpoint of path validation.
X.509 Certificate
The certificate format that carries issuer, subject, public key, Basic Constraints, Key Usage, and path length fields.
Frequently asked questions
What is an intermediate certificate in simple terms?
An intermediate certificate is a delegated CA certificate. It sits between a website's leaf certificate and a trusted root so the root does not have to sign everyday TLS certificates directly.
Is an intermediate certificate the same as a root certificate?
No. A root certificate is a trust anchor already trusted by the client, often self-signed. An intermediate certificate is signed by a root or higher intermediate and is trusted only when the client can build a valid chain to a trusted root.
Why do CAs use intermediate certificates?
Intermediate certificates let CAs keep root private keys offline and use narrower issuing keys for routine certificate operations. If an intermediate is compromised, the CA can revoke or replace it without replacing the root in every trust store.
Does a server need to install the intermediate certificate?
Yes. TLS servers should send the leaf certificate plus the required intermediate certificates. Clients may have cached intermediates, but relying on client fetching or cache behavior causes avoidable compatibility failures.
Should a server send the root certificate too?
Usually no. Clients should already have trusted roots in their trust stores. Servers normally send the leaf and intermediate certificates needed to connect that leaf to a root the client trusts.
What is a pathLen constraint?
The pathLen constraint is part of the Basic Constraints extension. It limits how many non-self-issued CA certificates may appear below a CA certificate in a valid path, which helps stop an intermediate from creating deeper CA hierarchies than policy allows.
Can an intermediate certificate issue another intermediate?
Only if its Basic Constraints, Key Usage, pathLen constraint, and CA policy allow it. Many public TLS issuing intermediates are constrained so they issue leaf certificates, not additional subordinate CAs.
References
Explore authoritative guidance and frameworks related to intermediate certificate.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.