SSL Certificate Chain: What It Is and How It Validates HTTPS Trust

The SSL certificate chain — also called the chain of trust — is the ordered sequence of digital certificates that links your website's certificate to a Root Certificate Authority trusted by browsers. Without a complete chain, the browser cannot verify your HTTPS and displays a security error.

Why the certificate chain exists

Browsers and operating systems ship with a pre-loaded list of trusted root certificates. However, certificate authorities (CAs) do not sign your certificate directly with the root key — that would be an enormous risk. If the root key were ever compromised, every certificate signed by it would instantly lose validity.

To contain that risk, CAs use a delegation architecture:

• The root CA signs one or more intermediate certificates.
• The intermediate certificate signs your domain certificate (also called the end-entity or leaf certificate).
• The root stays offline and tightly protected.

The result is a three-link chain: root → intermediate → domain certificate. Each link carries the digital signature of the one above it, enabling end-to-end trust verification.

The three links in the chain

Root certificate

The foundation of trust. It is self-signed and comes pre-installed in the certificate stores of Windows, macOS, iOS, Android, Firefox, and other browsers. DigiCert, Sectigo, Let's Encrypt, and other CAs each have their own root certificates in those lists.

The root's private key is held in offline HSM devices. It is used rarely and only to sign intermediate certificates.

Intermediate certificate

Acts as the bridge between the root and your domain certificate. Some CAs use one level of intermediates; others use two. The advantage: if an intermediate is compromised, the CA can revoke and replace it without touching the root.

It is the web server's responsibility to send the intermediate certificate alongside the domain certificate. If the server omits it, the browser must fetch it on its own (AIA fetching), which can fail or add latency.

Domain certificate (leaf)

The certificate you purchase for your site. It contains your domain name, the server's public key, and the intermediate's signature. Validity periods are typically 90 days (Let's Encrypt) or 1 year (commercial CAs).

How the browser validates the chain

When a visitor reaches your site over HTTPS, validation happens in milliseconds:

1. The server sends the domain certificate and the intermediate(s).
2. The browser verifies the domain certificate's signature using the intermediate's public key.
3. It verifies the intermediate's signature using the root's public key.
4. It checks that the root is in its trusted store.
5. It verifies that no certificate in the chain has been revoked (via OCSP or CRL).
6. It checks the validity dates of each link.

If all steps pass, the browser shows the padlock and establishes an encrypted session. If any link is missing, revoked, or expired, the browser shows a security error that drives visitors away.

Common certificate chain problems

The most frequent error is an incomplete chain: the server serves only the domain certificate without the intermediate. Chrome and Firefox can compensate with AIA fetching in some cases, but Safari and iOS are stricter and show the error directly. AIA fetching also adds an extra HTTP request that slows the handshake.

To diagnose your chain, use Qualys SSL Labs (ssllabs.com/ssltest) or run openssl s_client -connect yourdomain.com:443 -showcerts from a terminal. Find more SSL guides in our SSL security section.

How to build and serve the chain correctly

When your CA delivers your certificate, it typically includes a file named ca_bundle.crt, chain.pem, or similar, containing the necessary intermediates.

For Apache, the correct directives are:

SSLCertificateFile /path/to/domain.crt
SSLCertificateKeyFile /path/to/privkey.pem
SSLCertificateChainFile /path/to/ca_bundle.crt

On modern Apache (2.4.8+) you can also concatenate the domain certificate and intermediates into a single PEM file and use only SSLCertificateFile. The correct order inside that file is: domain certificate first, then intermediates from closest-to-leaf toward the root — do not include the root certificate itself (the browser already has it).

For Nginx:

ssl_certificate /path/to/fullchain.pem;      # domain + intermediates concatenated
ssl_certificate_key /path/to/privkey.pem;

Let's Encrypt automatically generates the fullchain.pem file in the correct order. If you use another provider, you may need to build that file manually.

Need help setting up your certificate chain correctly? The team at elenlace.com can install and verify your SSL on any server, error-free.

Key takeaways

• The SSL certificate chain connects your domain certificate to a recognized root CA through one or more intermediate certificates.
• Each link in the chain carries the digital signature of the one above it, establishing an unbroken line of trust.
• The web server must always send the domain certificate together with the intermediates; the root is never sent because the browser already has it.
• An incomplete chain is the most common cause of SSL errors that have nothing to do with the certificate itself.
• Tools like SSL Labs or openssl s_client let you verify the full chain in seconds.

Further reading

Other providers and guides worth comparing:

• HostGator México
• Hostinger
• HubSpot