An SSL certificate chain, or chain of trust, is the sequence of certificates that links a website's certificate to a Root CA that the browser already trusts. In most cases, the chain looks like this: the website certificate (leaf) — an intermediate certificate (Intermediate CA) — a root certificate (Root CA). Thanks to this connection, the browser can verify that the certificate was indeed issued by a trusted certificate authority rather than fabricated by an unknown source.
Preserving the correct order in the chain of trust matters not only for the certificate itself, but also for the website to work correctly across different browsers and for compatibility with operating systems and client devices. Even with a perfectly valid certificate, the connection will still fail if the server sends an incomplete chain of trust. If you're new to this topic, check out another article from our knowledge base — what is an SSL certificate. It covers the basics of SSL/TLS certificates.
What the chain of trust consists of
To better understand how an SSL certificate chain works, just remember the structure shown below:
Root CA — Intermediate CA — Leaf certificate
Let's take a closer look at each link in this chain of trust.
Root CA
The Root CA is a root certificate authority that already has built-in trust from the browser or operating system. It's the top link in the chain of trust. It lives in the trust store — a special storage location for trusted certificates.
The trust store is a built-in feature of operating systems and web browsers, so the web server doesn't need to send the root certificate to the client — thanks to the trust store, a trusted root certificate is already recognized in advance. Since the Root CA is a top-level certificate, it carries its own digital signature.
It's worth noting, though, that a root CA and a self-signed certificate aren't quite the same thing in practice. A root certificate is indeed self-signed, but what sets it apart is that it's installed as a trust anchor in the trust store. A regular self-signed certificate for a website doesn't get that kind of trust automatically.
Intermediate CA
The Intermediate CA is an intermediate certificate. It occupies the middle position in the chain of trust — between the root certificate and the website's certificate. Here's how it works: the Root CA signs the Intermediate CA's certificate, and the Intermediate CA then issues a certificate for a specific domain.
A chain of trust can include several intermediate certificates. In that case, they're labeled as Intermediate CA 1, Intermediate CA 2, and so on. This setup exists to provide stronger security for the certificate authority. The reason is simple: if the Root CA issued certificates directly to websites, it would seriously undermine security. Using an intermediate link solves this problem.
Even if one of the Intermediate CAs gets compromised, the fallout can be contained without putting the root key at direct risk.
Leaf certificate
The leaf certificate, or end-entity certificate, is the certificate issued for a specific website. Since it's signed by an Intermediate CA, the browser needs to confirm that it hasn't been tampered with and that it's properly linked to a trusted Root CA.
The full cryptographic chain looks like this:
website certificate — signed by Intermediate CA — signed by Root CA
In this chain, the server sends the leaf certificate along with the required intermediate certificates. Under a normal configuration, the root certificate doesn't need to be sent, since it should already be present in the client's trust store.
How the browser verifies the chain
When a user opens an HTTPS site, the server sends certain certificates to the browser. In simplified terms, the process looks like this:
The server sends the leaf certificate along with the intermediate certificates. At this point, the client receives the website's certificate plus the necessary links in the chain.
The browser determines who the website certificate was issued to. It checks the domain name, expiration date, and other certificate parameters.
The cryptographic signature is verified. The browser checks whether the leaf certificate was actually signed by the corresponding intermediate certificate authority.
The intermediate certificate is verified. Its signature must match the next link in the chain — either another Intermediate CA or the Root CA.
The chain must ultimately lead to a trusted root. The browser or operating system looks for the matching Root CA in its trust store.
Additional trust conditions are checked. Depending on the client, this can include the certificate's intended use, algorithms, CA constraints, revocation status, and other parameters.
If all the required conditions are met, the browser can consider the certificate trusted. The root certificate isn't part of the normal certificate transmission from the web server — the server shouldn't send it along with the leaf and intermediate certificates. A trusted root is typically not transmitted by the server at all; it's already present on the client's side, in the trust store. The root certificate file could theoretically sit on the server as part of a local configuration or CA bundle, but it doesn't need to be sent to the browser for a regular HTTPS connection.
Why the server needs to send the full chain
HTTPS issues often come up when the server is only configured to send the leaf certificate.
Picture this scenario:
Server — Leaf certificate
But the client needs to verify:
Leaf — Intermediate — Root
If the intermediate certificate is missing from the server's response and the client has no other way of obtaining or locating it, a complete chain can't be built. That's exactly why a properly configured HTTPS setup normally has the server send the leaf certificate together with the required intermediate certificates.
This becomes especially noticeable across different devices and software platforms. One client might already have the needed intermediate certificate in its local store or be able to fetch it another way, while another client might not. A site that loads fine on one device can throw an error on another if the chain isn't set up correctly.
Typical symptoms include messages like:
incomplete certificate chain;
unable to get local issuer certificate;
certificate verify failed.
The exact wording depends on the browser, operating system, and software being used.
Important to keep in mind: a chain-related issue doesn't necessarily mean the SSL certificate itself is expired or invalid. The leaf certificate can be perfectly valid while the server simply fails to deliver the associated intermediate certificates correctly.
For site owners running a VPS, this is one of the reasons automatic SSL setup tends to be more convenient than manual configuration. If the control panel in use supports automatic certificate and chain installation, it can add the required intermediate certificates to the web server configuration on its own.
When using a VPS from Leneex, you should check the specific behavior for your chosen control panel, since the capabilities of cPanel, Plesk, DirectAdmin, FASTPANEL, and HestiaCP can differ.
How to check the certificate chain yourself
You can check an HTTPS chain in two convenient ways: through an online service or from the command line.
Option 1. SSL Labs
For a quick site check, we recommend using the SSL Server Test from Qualys SSL Labs. The service analyzes the configuration of a public SSL/TLS server and shows information about certificates, the chain of trust, and other HTTPS parameters.
SSL Server Test — Qualys SSL Labs" (https://www.ssllabs.com/ssltest)Just enter the domain name and run the check. If the chain is misconfigured, the report will help you pinpoint which link is missing or causing the problem.
Option 2. OpenSSL
For a more technical check, you can use OpenSSL. The current OpenSSL 3.6 documentation confirms the availability of the s_client command along with the -connect, -servername, -showcerts, and -verify_return_error options.
It's important to understand the difference between viewing the certificates sent by the server and performing a full chain verification: the -showcerts option displays the list of certificates the server sent to the client, not an automatically confirmed, verified chain.
For example, to view the certificates a server sends during an HTTPS connection:
openssl s_client -connect YOUR_SITE.com:443 -servername YOUR_SITE.com -showcertsHere, YOUR_SITE.com should be replaced with the domain you're checking.
The -servername option matters for servers that use SNI and host multiple HTTPS sites on a single IP address. OpenSSL's own documentation notes that -showcerts displays the certificates sent by the server, and on its own doesn't mean the chain has been successfully verified.
For diagnosing verification errors, you can use OpenSSL's verification modes, but the exact command should be chosen based on the OpenSSL version, the trust store in use, and what exactly you're trying to check. s_client is a diagnostic tool and, by default, can continue running even if certain verification errors occur; -verify_return_error changes that behavior.
Conclusion
The chain of trust is the mechanism that links a specific website's certificate to a root certificate authority already trusted by the browser. In a typical setup, it consists of the site's leaf certificate, one or more intermediate certificates, and a trusted Root CA.
The main practical task for a site owner is to configure the server correctly so it sends the leaf certificate along with the required intermediate certificates. The root certificate itself is usually not sent — it's already present in the operating system's or browser's trusted store.
If you're using a virtual server from Leneex, how the chain is configured depends on your chosen control panel and its automatic SSL installation capabilities. You won't need to assemble a chain file manually — the necessary intermediate certificates get installed as part of the SSL setup process.
Learn more about Leneex SSL certificates on the service page: there you can choose the right option and check how automatic certificate installation works in the control panel you use.
