An SSL certificate chain is the ordered path that connects a website’s certificate to a certificate authority that a browser or operating system already trusts.

It normally contains a leaf certificate for the website, one or more intermediate CA certificates, and a root CA certificate held in the device’s trust store.

The browser checks the signatures and rules along that path before it trusts the site’s identity. If the server omits a required intermediate certificate, some visitors may see a certificate warning even when the leaf certificate is current and names the correct domain.

People still say SSL certificate, but modern web connections use TLS. The chain mechanism belongs to the X.509 public-key infrastructure used by TLS.

The chain has three certificate roles

Role	Identifies	Signed by	Where it normally comes from
Leaf certificate	Your website or service	An intermediate CA	Sent by your server
Intermediate certificate	A subordinate certificate authority	Another intermediate or root CA	Sent by your server
Root certificate	A trust anchor	Usually itself	Stored in the browser or operating system

The server sends the leaf and intermediate certificates. The browser completes the path with a root it already trusts.

The order matters. Each certificate names its issuer, and the next certificate in the path supplies the public key used to verify that issuer’s signature.

RFC 5280 calls this certification path validation.

Leaf certificate

The leaf, end-entity or server certificate identifies the website at the end of the chain. Its Subject Alternative Name extension lists the hostnames it covers, such as example.com and www.example.com.

It also contains the site’s public key, validity dates and permitted uses.

Your web server pairs this public certificate with the matching private key. The private key does not belong in the chain and must never leave the server or authorised key-management system.

Intermediate CA certificate

An intermediate CA sits between the site and the root. Certificate authorities use intermediates to issue leaf certificates without keeping a root private key online for everyday signing.

A chain can contain more than one intermediate. The server must usually send every intermediate the client needs to build a path from the leaf towards a trusted root.

Root CA certificate

The root acts as the trust anchor. Browser and operating-system vendors maintain root stores and decide which roots their products trust.

A web server normally does not need to send the root because the client already has it. Sending a root does not make an untrusted root trusted.

The CA/Browser requirements apply across publicly trusted certificate chains, from root authorities through subordinate authorities to subscriber certificates.

A live Truehost chain shows the issuer path

I checked truehost.co.uk with SSL Shopper.

The result showed the Truehost UK leaf certificate issued by WE1, followed by the WE1 intermediate and a GTS Root R4 certificate in the displayed path.

The checker also reported that the correct intermediates were installed.

The issuer of one certificate leads to the next certificate in the displayed path.

The exact leaf certificate, dates and path can change when a site renews its certificate, changes provider or serves a different chain. The durable lesson is how the issuer and subject fields link the certificates.

What the browser validates

A complete chain supplies the certificates, but completeness alone does not make the connection valid. During path validation, the client also checks whether:

• each certificate’s signature verifies against its issuer;

• the current time falls within the relevant validity periods;

• the requested hostname appears in the leaf certificate;

• certificate constraints allow the certificate to act in its position;

• the chain ends at a root the client trusts; and

• the certificate meets the client’s policy and revocation requirements.

This explains why installing an intermediate fixes only one class of SSL error. A complete chain cannot repair an expired certificate, wrong hostname, revoked certificate or mismatched private key.

Different clients can build different valid paths. Cross-signed certificates give clients more than one route to a trust anchor, and device trust stores do not all contain the same roots.

Let’s Encrypt documents current and historical chains for this reason.

The server should send the leaf and intermediates

During the TLS handshake, the server presents its leaf certificate followed by the intermediate certificates needed to reach a trusted root.

The sequence runs from the website certificate towards the root.

A typical PEM bundle looks like this:

-----BEGIN CERTIFICATE-----
leaf certificate for example.com
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
intermediate CA certificate
-----END CERTIFICATE-----

Do not add the private key to a public certificate bundle. Server software normally references it through a separate key directive or secure service.

Certbot uses filenames that make the distinction clearer:

File	Contents	Common use
cert.pem	Leaf certificate only	Inspection or software that accepts a separate chain
chain.pem	Intermediate certificate or certificates	Separate chain input where supported
fullchain.pem	Leaf first, then intermediates	Nginx and modern Apache certificate input
privkey.pem	Private key	Separate protected key input

The current Certbot guide defines fullchain.pem in that order. Nginx uses the same leaf-first ordering for its ssl_certificate file.

An incomplete chain can fail unevenly

An incomplete chain usually means the server sent its leaf certificate but omitted an intermediate.

The controlled incomplete-chain.badssl.com test page demonstrates that condition.

The test deliberately omits an intermediate to show why some clients cannot complete the trust path.

One browser may still open such a site because it cached the missing intermediate from an earlier visit or fetched it from the Authority Information Access URL.

Another browser, mobile device, API client or monitoring service may fail.

That split behaviour is a warning sign. Do not assume the chain is correct because the site opens on your usual laptop.

Common symptoms include:

• unable to get local issuer certificate;

• unable to verify the first certificate;

• a trust warning on some devices but not others;

• command-line or API clients failing while a desktop browser succeeds; and

• an online checker reporting a missing or incomplete chain.

How to inspect a certificate chain

Check it in a browser

Most desktop browsers expose certificate details for the current HTTPS page. In that viewer, look for a certification path or hierarchy that starts with the website and leads through one or more issuers to a trusted root. The location and labels vary by browser version.

The browser view proves what that client built, not necessarily every certificate the server sent. Cached intermediates and alternate paths can affect the result.

Query the server with OpenSSL

Run this from a machine with OpenSSL:

openssl s_client -connect example.com:443 -servername example.com -showcerts

The -servername value sends Server Name Indication, which matters when several HTTPS sites share one address. Inspect the Certificate chain section and the final verification result.

To test a local leaf against a supplied chain and trust store, use openssl verify with the files appropriate to your environment. Do not treat a successful syntax check as proof that the public server presents the same files.

Use an external checker

Test from a clean external service after deployment. That avoids your browser cache and checks the public endpoint rather than the files on disk. Record the tested hostname, port, time and result so another administrator can reproduce the check.

Fix a missing intermediate certificate

Start with the certificate files supplied by your certificate authority or automated client. Do not download an intermediate from an unrelated forum or reuse a bundle from another server without checking its subject, issuer and validity.

• Back up the working configuration. Save the current certificate path, key reference and server block before changing them.
  

• Obtain the correct chain. Use the CA’s download page or the current Certbot files for that exact certificate.
  

• Build the leaf-first bundle. Put the server certificate first, followed by its intermediate or intermediates. Do not place the root first.
  

• Update the server reference. Nginx should point ssl_certificate to the combined chain file. Apache 2.4.8 and later can load the leaf and intermediates through SSLCertificateFile.
  

• Validate before reload. Run the server’s configuration test, then reload only after it passes.

nginx -t
apachectl configtest

• Retest the public endpoint. Query the exact production hostname with OpenSSL and an external checker. Also test a browser or client that did not previously visit the site.

Nginx’s HTTPS guide warns that the server certificate must come before chained certificates in the combined file. A wrong order can prevent Nginx from matching the certificate to its private key.

If you use cPanel or managed hosting, the platform may assemble the chain automatically. Check the installed certificate and issuer path after every renewal rather than assuming automation completed every step.

Keep chain checks in the renewal process

Certificate renewal replaces more than an expiry date. The issuer, intermediate or preferred path may change.

A deployment that copies only the new leaf can reintroduce an incomplete chain even when the previous installation worked.

After every renewal:

• confirm the public hostname presents the new leaf;

• confirm the intermediate path remains complete;

• test the hostname and expiry dates;

• check at least one external client; and

• monitor for TLS errors after deployment.

Our renewal guide covers the wider renewal checks. If you need a certificate for a UK website, compare our SSL certificates and choose the validation level that fits the site.

The chain connects your certificate to existing trust

The leaf certificate identifies your website. Intermediates carry that identity towards a root. The root anchors the path in a trust store controlled by the browser or operating system.

Your server normally sends the leaf and every required intermediate, in that order. The client supplies the trusted root.

When one intermediate is missing, cached or fetched certificates can hide the fault on some devices, so test the public endpoint from more than one client after installation and renewal.

---