When a browser validates an SSL/TLS certificate, it does not just check the certificate itself — it verifies an entire certificate chain that links your server's certificate back to a root authority that browsers inherently trust. A missing or incomplete chain is one of the most common causes of SSL errors, even when the certificate itself is valid.
What Is a Certificate Chain?
A certificate chain (also called a certificate path or chain of trust) is a sequence of SSL certificates, each signed by the one above it, that forms a trusted link from your website's certificate up to a root Certificate Authority (CA) that browsers trust.
The chain typically consists of three levels:
- Root CA certificate: A self-signed certificate from a trusted Certificate Authority (e.g., DigiCert, Sectigo, Let's Encrypt's ISRG Root). These are pre-installed in operating systems and browsers.
- Intermediate CA certificate: A certificate signed by the root CA. CAs use intermediate certificates to sign end-entity certificates, keeping the root certificate offline for security.
- End-entity certificate (leaf certificate): Your server's certificate, signed by the intermediate CA. This is the certificate your server sends to browsers.
Root CA (trusted by browsers)
└── Intermediate CA (signed by Root CA)
└── example.com certificate (signed by Intermediate CA)How Certificate Chain Verification Works
When a browser connects to your HTTPS site, it performs the following steps:
- The server sends its certificate (and should include any intermediate certificates).
- The browser checks that the server certificate is signed by a trusted entity — it looks for the Intermediate CA's signature.
- The browser then verifies that the Intermediate CA's certificate is signed by a trusted Root CA in its trust store.
- If any link in the chain is missing or invalid, the browser displays an SSL error.
Why Intermediate Certificates Exist
Root CA private keys are extremely sensitive. If a root key were compromised, all certificates signed by that root would need to be revoked — a catastrophic event for internet security. To minimize risk, CAs keep their root keys offline in hardware security modules and use intermediate CAs for day-to-day certificate signing.
If an intermediate CA is compromised, the CA can revoke that intermediate certificate without affecting the root or other intermediates. This containment is why the intermediate layer exists.
What Is an Incomplete Certificate Chain?
An incomplete chain error ("unable to get local issuer certificate" or "certificate chain incomplete") occurs when your server sends only the leaf certificate without the intermediate certificate(s). Browsers cannot verify the chain because the link between your certificate and the root CA is missing.
# Check if your server sends the complete certificate chain
openssl s_client -connect example.com:443 -showcerts
# You should see multiple certificates in the output
# (leaf certificate + intermediate certificate)
# If you only see one certificate, the chain is incompleteHow to Fix an Incomplete Certificate Chain
The fix depends on how you are serving your certificate:
Bundle the Full Chain
Most CAs provide a "full chain" or "CA bundle" file when you download your certificate. This file contains your certificate concatenated with all intermediate certificates. Configure your server to use the full chain file, not just the leaf certificate.
# Create a full chain bundle manually
cat your-certificate.crt intermediate.crt > fullchain.crt
# Or with Let's Encrypt (Certbot), the full chain is already provided
# at: /etc/letsencrypt/live/example.com/fullchain.pemNginx Configuration
server {
listen 443 ssl;
ssl_certificate /etc/ssl/fullchain.pem; # Contains cert + intermediate
ssl_certificate_key /etc/ssl/private.key;
}Apache Configuration
SSLCertificateFile /etc/ssl/your-certificate.crt
SSLCertificateKeyFile /etc/ssl/private.key
SSLCertificateChainFile /etc/ssl/intermediate.crtCertificate Chain Structure Examples
Let's Encrypt Chain
ISRG Root X1 (Root CA — trusted by browsers)
└── Let's Encrypt R11 (Intermediate CA)
└── example.com (Your certificate)DigiCert Chain
DigiCert Global Root G2 (Root CA)
└── DigiCert TLS RSA SHA256 2020 CA1 (Intermediate CA)
└── example.com (Your certificate)Cross-Signed Certificates and Multiple Chains
Some certificates can be verified through more than one chain. For example, Let's Encrypt's intermediate certificates are cross-signed by IdenTrust, allowing them to be trusted by older devices that don't have the ISRG Root X1 in their trust store. Browsers follow whichever chain leads to a trusted root in their store.
Checking Your Certificate Chain
Use the ShowDNS SSL Checker to verify that your server is sending a complete certificate chain and that all certificates are valid and not expiring soon. The tool shows the full chain from your leaf certificate up to the root.
Frequently Asked Questions
How many intermediate certificates can there be?
A chain can technically have multiple intermediate certificates, though two or three levels total (root + one or two intermediates + leaf) is most common. Longer chains add latency and complexity.
Does the order of certificates in the chain file matter?
Yes. The convention is: leaf certificate first, then intermediate(s) in order, with the root last (though the root is often omitted since browsers have it). Some servers are strict about order; others are not.
What is a cross-signed certificate?
A cross-signed certificate is signed by two different CAs — allowing it to be verified through two different chain paths. This is used to extend trust to older devices or operating systems that might not have newer root CAs installed.
Can I verify my certificate chain without tools?
You can use openssl s_client -connect example.com:443 -showcerts to see the certificates your server sends. If you see more than one certificate in the output, you are serving a chain. If you see only one, the chain is incomplete.