PEM and X.509 Certificate Chains Explained: Leaf, Intermediate and Root Certificates

Overview

A certificate chain links a target certificate to a trust anchor

An X.509 certificate contains a subject identity, a public key, validity dates, extensions and an issuer signature. A relying application does not trust an end-entity certificate merely because it is well formed. It builds or receives a certification path from that target certificate through any required intermediate certificate authorities to a locally configured trust anchor.

Leaf / end-entity certificate
  signed by ↓
Intermediate CA certificate
  signed by ↓
Root CA / configured trust anchor

RFC 5280 defines certification path validation as the process that verifies the binding between the target certificate's subject name or alternative name and public key, based on a trust anchor and the constraints along the path.^[1]

Encoding and format

X.509 describes the certificate; PEM is a textual wrapper

The certificate itself is an ASN.1 structure commonly encoded as binary DER. RFC 7468 defines the familiar textual representation that wraps Base64-encoded certificate bytes between matching boundaries:^[2]

-----BEGIN CERTIFICATE-----
MIIC...Base64-encoded DER certificate bytes...AB
-----END CERTIFICATE-----

A file can contain one certificate block or several concatenated certificate blocks. The CERTIFICATE label does not tell you whether a block is a leaf, intermediate, or root. Its role is determined by certificate fields, signatures, constraints, how it is used, and whether the relying system treats it as a trust anchor.

Filename extensions such as .pem, .crt, .cer, and .chain are operational conventions, not reliable proof of the contained object or encoding. Inspect the boundaries and decode the certificate fields.

Certificate roles

Leaf, intermediate and root certificates serve different purposes

Self-signed does not automatically mean trusted

A self-signed certificate verifies its own signature with its own public key. That proves internal consistency, not external trust. A root becomes trusted because the operating system, browser, application, device, or interface configuration explicitly accepts its key and constraints as a trust anchor.

Self-issued and self-signed are not identical concepts

A certificate is self-issued when its issuer and subject names are the same. It is self-signed only when its signature verifies with its own public key. Name equality alone is not enough to establish either a parent relationship or trust.

Path processing

Path building and path validation are separate jobs

Path building assembles candidate certificates between the target certificate and a trust anchor. Path validation evaluates a proposed path against signatures, validity, names, constraints, policies, critical extensions, and the selected trust anchor. RFC 4158 treats path building as a separate process because real PKI environments may contain multiple issuers, cross-certificates, missing certificates, and several possible trust anchors.^[4]

1. Start with the target certificate. For a TLS server, this is normally the certificate naming the server.
2. Find a plausible issuer. Subject/issuer names, Authority Key Identifier, Subject Key Identifier, and available certificate stores help identify candidates.
3. Verify the certificate signature. The candidate issuer's public key must verify the child certificate's signature.
4. Apply CA constraints. Check Basic Constraints, Key Usage, path length, Name Constraints, certificate policies, and unsupported critical extensions.
5. Continue toward a trust anchor. The path succeeds only when it terminates at a trust anchor accepted for this use.
6. Apply end-entity checks. Confirm time validity, intended EKU, hostname or application identity, revocation requirements, and local policy.

A chain viewer that merely compares issuer and subject names can identify likely relationships, but it cannot prove a valid certification path.

TLS presentation

A TLS peer normally sends the leaf first, followed by intermediates

The current TLS 1.3 specification requires the sender's certificate to be first in the certificate list. Each following certificate should directly certify the one before it. A certificate representing a trust anchor may be omitted because trust anchors are distributed independently.^[3]

Recommended TLS certificate list

1. api.example.test leaf certificate
2. Example Issuing CA intermediate
3. Example Policy CA intermediate, if required

Root trust anchor: normally omitted and already trusted by the client

Sending the root usually adds bytes without creating trust. A client that does not already trust that root will not normally begin trusting it merely because the server included it. The client must possess or select an acceptable trust anchor independently.

Worked example

Read a synthetic three-certificate hierarchy

Leaf certificate
  Subject: CN=api.example.test
  Issuer:  CN=Example Issuing CA 01
  Basic Constraints: CA:FALSE
  Extended Key Usage: TLS Web Server Authentication
  SAN: DNS:api.example.test

Intermediate certificate
  Subject: CN=Example Issuing CA 01
  Issuer:  CN=Example Root CA
  Basic Constraints: CA:TRUE, pathlen:0
  Key Usage: Certificate Sign, CRL Sign

Root certificate / trust anchor
  Subject: CN=Example Root CA
  Issuer:  CN=Example Root CA
  Basic Constraints: CA:TRUE

The names suggest a simple hierarchy, but a validator still needs to verify both certificate signatures, check CA constraints and validity, confirm the leaf's server-authentication purpose and SAN, and establish that Example Root CA is an accepted trust anchor.

Typical PEM files

leaf.pem
  -----BEGIN CERTIFICATE-----  (leaf)

intermediates.pem
  -----BEGIN CERTIFICATE-----  (issuing intermediate)
  -----BEGIN CERTIFICATE-----  (higher intermediate, if required)

fullchain.pem
  -----BEGIN CERTIFICATE-----  (leaf)
  -----BEGIN CERTIFICATE-----  (intermediate 1)
  -----BEGIN CERTIFICATE-----  (intermediate 2, if required)

private-key.pem
  [private-key block omitted: secret; never publish]

Names such as fullchain.pem are conventions and can vary by product. Confirm the actual blocks and the configuration field's expected order. A certificate bundle and its matching private key remain separate security objects even when a server configuration references both.

Common failures

Why a certificate can look correct but still fail

“Works in my browser” is not proof for another application

A browser and an integration service may use different trust stores, path-building algorithms, AIA retrieval behaviour, revocation settings, algorithm policies and certificate caches. A successful browser test proves only that the browser built an acceptable path and passed its own checks. Reproduce the test with the runtime and trust store used by the failing application.

Troubleshooting

A practical certificate-chain investigation sequence

1. Capture the exact presented certificates. Do not rely only on filenames or a management console label.
2. Identify the leaf. Check SAN, EKU, Basic Constraints, subject, issuer, validity, and public-key fingerprint.
3. List every intermediate. Record subject, issuer, serial number, SKI, AKI, CA constraints, and fingerprint.
4. Confirm ordering and completeness. For TLS, expect leaf first followed by required intermediates.
5. Verify candidate signatures. Name matching alone does not establish parentage.
6. Identify the relying system's trust anchor. Inspect the actual trust store used by the process, container, runtime, or appliance.
7. Validate at the failure time. Check the full path's validity periods and clock accuracy.
8. Apply service identity and purpose checks. Confirm SAN, EKU, Key Usage, Name Constraints, policies, and local profile requirements.
9. Review revocation and network policy. Determine whether CRL, OCSP, AIA, proxy, or firewall behaviour affects validation.
10. Compare successful and failing clients. Trust-store and path-building differences often explain inconsistent results.

The server sends the leaf and root but clients still fail

If an intermediate CA issued the leaf, that intermediate is missing from the presented chain. The root is not a substitute for the certificate that actually signed the leaf. Configure the server with the leaf followed by the required intermediate certificate or certificates.

The chain validates, but the TLS connection still fails

Continue beyond path validation. Check hostname or IP identity, EKU, supported signature algorithms, private-key availability, TLS versions, cipher negotiation, mutual-TLS client certificates, and application-specific policy.

Two intermediates have the same subject name

Do not select by name alone. Compare fingerprints, serial numbers, public keys, SKI/AKI values, validity periods, issuers, signatures, and the trust paths available to the relying client. Cross-signing can create several valid-looking candidates.

Checklist

What to define for certificate deployment and renewal

• The certificate's intended role: server, client, document signer, code signer, CA, or another profile.
• The required service identities, SAN values, EKUs, Key Usage, and policy OIDs.
• The exact leaf and intermediate bundle order expected by the server or application.
• Which root or trust-anchor set each relying environment uses.
• Whether AIA fetching, CRL retrieval, OCSP, or stapling is required and network-accessible.
• Minimum signature algorithms, public-key sizes, TLS versions, and other cryptographic policy.
• How the private key is generated, stored, protected, backed up, rotated, and proven to match the certificate.
• Renewal lead time for the leaf and awareness of intermediate or root expiry.
• Deployment testing from every relevant client runtime and network zone.
• Rollback, overlapping-certificate, cache-refresh, and emergency-revocation procedures.
• Monitoring for expiry, chain changes, hostname coverage, and failed handshakes.

Primary references

Certificate, PEM and TLS standards

1. RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile — certificate profiles and certification path validation.
2. RFC 7468: Textual Encodings of PKIX, PKCS, and CMS Structures — BEGIN/END boundaries and Base64 textual encoding for certificates and related objects.
3. RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3 — current TLS 1.3 certificate-list ordering and trust-anchor omission rules.
4. RFC 4158: Internet X.509 Public Key Infrastructure Certification Path Building — guidance on constructing paths in simple and complex PKI environments.

Local PKI profiles, trust-store policies, certificate authority practice statements, application requirements, and vendor implementation guides may impose additional constraints.