Every time someone visits a website over HTTPS, their browser verifies the site's identity through something called an SSL certificate chain. This process happens in milliseconds, completely invisible to the user, but it is the foundation of trust on the internet. If any link in that chain breaks, visitors see a security warning and most of them leave immediately.
Understanding how SSL certificate chains work is essential if you manage a server, run a website, or handle any kind of hosting infrastructure. Misconfigured certificate chains are one of the most common causes of SSL errors, and they are surprisingly easy to fix once you understand what is actually happening.
What Is an SSL Certificate
An SSL certificate, more accurately called a TLS certificate since SSL has been deprecated in favor of TLS, is a digital document that proves a website is who it claims to be. When you visit a website, the certificate tells your browser that the server actually belongs to that organization and not someone impersonating it.
The certificate contains several pieces of information. It includes the domain name it was issued for, the organization that owns it, the certificate authority that issued it, the certificate's public key, its validity period, and a digital signature. That digital signature is where the chain of trust begins.
How the Certificate Chain Works
A certificate chain, also called a chain of trust or certificate hierarchy, is a sequence of certificates where each one vouches for the next. Think of it like a chain of references. Your browser trusts a root certificate authority. That root CA signed an intermediate certificate. That intermediate certificate signed your website's certificate. Each link in the chain validates the one below it.
The chain typically has three levels. At the top is the root certificate, which is self-signed and pre-installed in your browser or operating system's trust store. In the middle are one or more intermediate certificates, issued by the root CA. At the bottom is the end-entity certificate, which is the one installed on your server for your specific domain.
Root Certificates
Root certificates are the trust anchors of the entire system. They belong to certificate authorities like DigiCert, Let's Encrypt (via ISRG), Sectigo, and GlobalSign. Your operating system and browser ship with a pre-installed list of trusted root certificates. On Windows, you can see them in the Certificate Manager. On Linux, they are typically stored in /etc/ssl/certs.
Root CAs rarely sign end-entity certificates directly. If a root CA's private key were compromised, every certificate it ever signed would need to be revoked. That would break millions of websites simultaneously. Instead, root CAs create intermediate certificates and use those to sign individual website certificates. This way, if an intermediate is compromised, only that intermediate's certificates are affected.
Intermediate Certificates
Intermediate certificates sit between the root and your server's certificate. They are signed by the root CA and in turn sign your domain's certificate. There can be one or several intermediates in a chain. Let's Encrypt uses one intermediate (R10 or R11), while some commercial CAs use two or three levels of intermediates.
The critical thing to understand is that your server must send the intermediate certificates to the browser during the TLS handshake. Browsers have root certificates pre-installed, but they do not have intermediates. If your server only sends the end-entity certificate without the intermediates, the browser cannot build the chain back to a trusted root and will show an error.
End-Entity Certificates
The end-entity certificate, sometimes called the leaf certificate or server certificate, is the one issued specifically for your domain. This is what you install on your web server, VPS, or dedicated server. It contains your domain name, your public key, and the signature of the intermediate CA that issued it.
The TLS Handshake Step by Step
When a browser connects to your server over HTTPS, a TLS handshake occurs before any data is exchanged. Here is what happens in that process.
The client sends a ClientHello message to the server, listing the TLS versions and cipher suites it supports. The server responds with a ServerHello, choosing the TLS version and cipher suite to use. The server then sends its certificate chain to the client, including the end-entity certificate and all intermediate certificates.
The client verifies the chain by checking each certificate's signature against the one above it. It starts with the end-entity certificate, verifies it was signed by the intermediate, then verifies the intermediate was signed by a root in its trust store. If every signature checks out and no certificates are expired or revoked, the handshake continues.
The client and server then exchange key material to establish a shared secret, and from that point forward all communication is encrypted. The entire handshake takes about 50 to 100 milliseconds on a modern connection. With TLS 1.3, it is even faster because the handshake requires fewer round trips.
Common SSL Certificate Chain Errors
Most SSL errors that server administrators encounter are related to the certificate chain rather than the certificate itself. Here are the most frequent issues and how to resolve them.
Incomplete Certificate Chain
This is the single most common SSL error. It happens when your server sends the end-entity certificate but not the intermediate certificates. Some browsers, particularly Chrome and Firefox on desktop, can sometimes fetch missing intermediates on their own through a mechanism called AIA fetching. But mobile browsers, API clients, and command-line tools like curl usually cannot. The result is that your site works fine in Chrome on your laptop but fails on Android phones or when other servers try to connect to your API.
The fix is to configure your web server to send the full chain. In Nginx, you concatenate your certificate and the intermediate certificates into a single file and point ssl_certificate to that file. In Apache, you use the SSLCertificateChainFile directive or include the intermediates in the SSLCertificateFile. With Let's Encrypt and Certbot, the fullchain.pem file already contains both your certificate and the intermediates, so use that instead of cert.pem.
Expired Intermediate Certificate
Intermediate certificates have expiration dates just like your server certificate. If an intermediate expires, every certificate it signed becomes untrusted even if those individual certificates have not expired yet. This happened famously with the Let's Encrypt DST Root CA X3 cross-sign expiration in 2021, which broke HTTPS on millions of devices running older software.
To avoid this, keep your certificate chain files updated when you renew your certificates. Certificate authorities occasionally rotate their intermediates, and your renewed certificate may be signed by a different intermediate than your previous one.
Wrong Certificate Order
The certificates in your chain file must be in the correct order. The end-entity certificate comes first, followed by the intermediate that signed it, followed by the next intermediate if there is one. The root certificate should not be included because clients already have it. If the order is wrong, some clients will fail to validate the chain even though all the right certificates are present.
How to Check Your SSL Certificate Chain
There are several ways to verify that your certificate chain is correctly configured.
Using OpenSSL from the command line is the most reliable method. Run openssl s_client -connect yourdomain.com:443 -showcerts and examine the output. It will show you every certificate the server sends, in order. You should see your end-entity certificate first, then the intermediate certificates. If you only see one certificate, your chain is incomplete.
Online tools like SSL Labs SSL Server Test provide a detailed analysis of your certificate chain along with an overall grade. They will flag missing intermediates, weak cipher suites, and protocol issues. Qualys SSL Labs is the industry standard for this kind of testing.
In your browser, you can click the padlock icon in the address bar and view the certificate details. Most browsers show the full chain hierarchy, letting you see the root, intermediates, and end-entity certificate. This is useful for quick checks but does not catch all issues that affect non-browser clients.
Setting Up SSL on Your Server
If you are running a VPS or dedicated server, setting up SSL correctly is straightforward once you understand the chain concept.
Using Let's Encrypt with Certbot
Let's Encrypt is the most popular free certificate authority. Certbot automates the entire process of obtaining and renewing certificates. On Ubuntu or Debian, install Certbot with apt install certbot python3-certbot-nginx, then run certbot --nginx to automatically configure SSL for your Nginx sites. Certbot handles the certificate chain correctly by default, generating a fullchain.pem that includes both your certificate and the intermediate.
Nginx Configuration
In Nginx, the ssl_certificate directive should point to the full chain file, not just the server certificate. The ssl_certificate_key directive points to your private key. A properly configured Nginx SSL block includes ssl_protocols TLSv1.2 TLSv1.3 to disable older insecure protocols, and ssl_ciphers set to a modern cipher suite list. Enable ssl_stapling and ssl_stapling_verify to improve performance by allowing your server to provide OCSP responses directly instead of forcing clients to check certificate revocation separately.
Apache Configuration
Apache uses SSLCertificateFile for your server certificate and SSLCertificateChainFile for the intermediate certificates, though in newer versions of Apache you can combine them into SSLCertificateFile. Set SSLProtocol to all -SSLv3 -TLSv1 -TLSv1.1 to disable insecure protocols. Enable SSLUseStapling on and configure an SSLStaplingCache for OCSP stapling.
SSL Certificates and Server Performance
A common concern is whether SSL adds significant overhead to server performance. With modern hardware and TLS 1.3, the performance impact is negligible. The TLS 1.3 handshake requires only one round trip compared to two in TLS 1.2, and session resumption can reduce subsequent connections to zero round trips.
The encryption and decryption of data uses AES-GCM or ChaCha20-Poly1305 ciphers, both of which are hardware-accelerated on modern CPUs through AES-NI instructions. On a typical VPS or dedicated server, TLS adds less than one percent CPU overhead. The latency added by the handshake is usually 10 to 30 milliseconds, which is imperceptible to users.
If you are running a high-traffic site on a dedicated server or VPS, enabling HTTP/2 or HTTP/3 actually requires HTTPS, and both protocols significantly improve performance through multiplexing and header compression. So SSL does not just avoid slowing your site down, it enables protocols that make it faster.
Types of SSL Certificates
SSL certificates come in three validation levels, and the choice affects what information appears in the certificate but does not change the encryption strength.
Domain Validation (DV) certificates verify only that you control the domain. They are issued in minutes and are what Let's Encrypt provides. For most websites, VPS hosting panels, and APIs, DV certificates are perfectly adequate.
Organization Validation (OV) certificates verify your organization's identity in addition to domain ownership. The certificate authority checks business registration documents. These are common for business websites that want to display their company name in the certificate details.
Extended Validation (EV) certificates involve the most thorough verification process, including legal and operational checks. They used to display a green bar with the company name in browsers, but most browsers have removed that visual distinction. The security benefit over DV or OV is debatable, and many major companies have moved away from EV certificates.
Wildcard certificates cover a domain and all its subdomains at one level. A wildcard for *.example.com covers www.example.com, mail.example.com, and api.example.com, but not sub.api.example.com. Multi-domain (SAN) certificates can cover multiple different domains in a single certificate.
Certificate Transparency and Security
Certificate Transparency (CT) is a system that logs all issued certificates in publicly auditable logs. When a certificate authority issues a certificate, it must submit it to multiple CT logs. This makes it possible to detect misissued or fraudulent certificates quickly.
You can use CT logs to monitor your domain for unauthorized certificates. Services like crt.sh let you search for all certificates ever issued for your domain. If someone manages to get a certificate issued for your domain without your knowledge, CT logs will reveal it. Setting up CAA (Certificate Authority Authorization) DNS records adds another layer of protection by specifying which CAs are allowed to issue certificates for your domain.
Renewing and Automating Certificate Management
Let's Encrypt certificates are valid for 90 days, which encourages automation. Certbot sets up a systemd timer or cron job that automatically renews certificates before they expire. If you are using a different CA with longer validity periods, set calendar reminders well before expiration. An expired certificate will immediately break HTTPS access to your site.
For servers managed through hosting control panels, certificate renewal is usually handled automatically. On a VPS or dedicated server where you manage everything yourself, verify that automatic renewal is working by running certbot renew --dry-run after initial setup. Check your renewal hooks to make sure your web server reloads the new certificate after renewal.
Summary
An SSL certificate chain is the sequence of certificates that connects your server's certificate to a trusted root certificate authority. The chain typically consists of three levels: the root certificate pre-installed in browsers, one or more intermediate certificates, and your end-entity server certificate. Your server must send the complete chain minus the root during the TLS handshake for all clients to trust your certificate.
Most SSL errors come from incomplete chains, expired intermediates, or incorrect certificate order. Use tools like OpenSSL or SSL Labs to verify your chain is correct. On a VPS or dedicated server, Let's Encrypt with Certbot is the simplest way to get a properly configured certificate chain with automatic renewal. The performance overhead of modern TLS is negligible, and HTTPS enables faster protocols like HTTP/2 and HTTP/3 that actually improve your site speed.
Ready to Deploy?
Get a high performance VPS with instant setup, full root access, and 24/7 support.