Why Certificate Chains Break
Every SSL certificate your server presents to clients must form a complete chain of trust back to a root certificate authority that the client's browser or operating system trusts. When this chain is broken — whether by a missing intermediate, incorrect ordering, or an expired link — users see security warnings, API clients throw connection errors, and monitoring tools flag your site as insecure.
The most common cause of chain breakage is a misconfigured web server. Many administrators install their leaf certificate correctly but forget to include the intermediate certificates that bridge the gap between the leaf and the root. Other times, the intermediates are present but in the wrong order, which causes some TLS libraries to reject the chain entirely.
Certificate chain problems can be subtle. A site might load fine in Chrome but fail in Firefox, or work on macOS but throw errors on Android. These inconsistencies happen because different platforms maintain different root stores and have varying tolerance for incomplete chains. Chrome on Windows often fills in missing intermediates by caching them from other sites, masking the problem for many users while others still see errors.
What a Certificate Chain Looks Like
A properly constructed certificate chain has three levels in most deployments. The leaf certificate, also called the end-entity certificate, is issued for your specific domain. One or more intermediate certificates sit between the leaf and the root, each signed by the one above it. The root certificate lives in the client's trust store and is never sent by the server during the TLS handshake.
When a browser connects to your server, the server sends the leaf certificate followed by all intermediate certificates in order. The browser then walks up this chain, verifying each signature, until it reaches a root it trusts. If any link is missing or invalid, the chain verification fails and the connection is treated as untrusted.
Diagnosing Chain Problems with OpenSSL
The openssl command-line tool is the most reliable way to diagnose certificate chain issues. Unlike browsers, which may cache intermediates or apply platform-specific fixes, openssl gives you a raw view of exactly what the server is presenting.
Inspecting the Server's Certificate Chain
Use openssl s_client to connect to your server and display all certificates it sends during the handshake. The -showcerts flag tells openssl to print each certificate in PEM format, and -connect specifies the host and port to test.
echo | openssl s_client -connect example.com:443 -showcerts 2>/dev/nullThis command outputs the full TLS handshake details. Look for the certificate chain section, which begins with the server's leaf certificate and continues with any intermediate certificates the server provides. The number of certificates shown tells you immediately if intermediates are missing. A server serving only its leaf certificate shows exactly one certificate block, while a properly configured server shows two or more.
For a more focused view that shows only the chain structure, use the -brief flag with s_client to get a compact summary including the verification result.
echo | openssl s_client -connect example.com:443 -brief 2>/dev/nullThe verification result line tells you whether the chain is complete. If you see "Verification error: unable to verify the first certificate," the server is missing intermediate certificates. If verification succeeds with "Verification: OK," the chain is complete from the perspective of your system's trust store.
Decoding Individual Certificates
To inspect the details of each certificate in the chain, extract them individually and use openssl x509 to decode their contents. This reveals the subject, issuer, validity period, and extensions for each certificate.
echo | openssl s_client -connect example.com:443 -showcerts 2>/dev/null | awk '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/' > chain.pemOnce you have the certificates saved, decode them one at a time to trace the chain of issuers.
openssl x509 -in leaf.pem -text -noout | head -20
openssl x509 -in intermediate.pem -text -noout | head -20Pay close attention to the Issuer field of each certificate. The issuer of the leaf certificate must match the subject of the first intermediate. The issuer of that intermediate must match the subject of the next certificate up the chain. Any mismatch indicates a missing or incorrect intermediate certificate.
You can also verify the entire chain in a single command by providing the intermediate certificates in a separate file.
openssl verify -CAfile intermediate.pem leaf.pemIf the verification succeeds, the chain is valid. If it fails, openssl reports the specific error, such as "unable to get local issuer certificate" for a missing intermediate or "certificate has expired" for an expired certificate in the chain.
Common Chain Failure Scenarios
Missing Intermediate Certificates
This is by far the most frequent chain problem. The server administrator installs the leaf certificate but either forgets to install the intermediate bundle or points the server configuration to the wrong file. The result is a chain that ends abruptly at the leaf certificate with no path to a trusted root.
Symptoms include browsers showing "NET::ERR_CERT_AUTHORITY_INVALID" in Chrome or "SEC_ERROR_UNKNOWN_ISSUER" in Firefox. However, the problem may be masked on Windows systems where Chrome uses the operating system's certificate cache to fill in missing intermediates automatically. Always test with openssl to see the ground truth.
Wrong Intermediate Order
Some servers require intermediates in a specific order, typically from leaf to root. If the server configuration lists them in reverse order or jumbled, certain TLS libraries (notably OpenSSL-based ones used by Python, curl, and many backend services) fail to validate the chain even though all certificates are technically present.
# Correct order: leaf first, then intermediates toward root
cat leaf.pem intermediate1.pem intermediate2.pem > fullchain.pemExpired or Revoked Intermediates
Certificate authorities periodically rotate their intermediate certificates, issuing new ones before old ones expire. If your server configuration references an intermediate that has since expired, the chain breaks even though your leaf certificate is still valid. Always update your intermediate bundle when you renew your certificate, even if the CA's documentation suggests the old intermediates are still usable.
Fixing Chain Issues
Server-Side Configuration
For Nginx, the fix involves updating the ssl_certificate directive to point to a full chain file that contains both the leaf certificate and all intermediates, or using a separate ssl_trusted_certificate directive for the intermediates.
# Nginx: point to a combined fullchain file
ssl_certificate /etc/nginx/ssl/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/privkey.pem;
# Verify configuration and reload
nginx -t && systemctl reload nginxFor Apache httpd, use the SSLCertificateChainFile directive (Apache 2.4.8 and older) or include the intermediates in the same file as the leaf certificate with SSLCertificateFile.
# Apache: combined file approach
SSLCertificateFile /etc/apache2/ssl/fullchain.pem
SSLCertificateKeyFile /etc/apache2/ssl/privkey.pem
# Test configuration and restart
apachectl configtest && systemctl reload apache2After updating your server configuration, always restart or reload the service and then retest with openssl s_client to confirm the chain is complete.
Using OpsCheck SSL Tools for Verification
Once you have applied fixes, use the OpsCheck SSL Checker to verify the chain from an external perspective. This tool connects to your server and analyzes the complete certificate chain, flagging missing intermediates, ordering problems, and trust store compatibility issues across multiple browser and operating system configurations.
For deeper analysis of individual certificates, the OpsCheck SSL Decoder lets you paste any PEM-encoded certificate and instantly decode its subject, issuer, validity window, SAN entries, key usage, and extensions. This is invaluable for comparing certificates in your chain to verify correct pairing between issuers and subjects.
Verifying the Fix Across Platforms
A single successful openssl verification on your local machine does not guarantee the chain works everywhere. Different root stores have different sets of trusted roots, and some platforms are stricter about chain ordering than others. Use multiple verification tools and test from different operating systems when possible.
The SSLLabs Server Test at ssllabs.com provides a comprehensive chain analysis that tests against multiple trust stores simultaneously. It also catches edge cases like chains that are technically valid but excessively long, which can cause performance issues and compatibility problems with older clients.
Set up ongoing monitoring after fixing chain issues. Certificate chains can break again when intermediates expire or when CAs rotate their infrastructure. A scheduled check using openssl or a monitoring tool catches these problems before they affect users.
# Simple monitoring one-liner for cron
echo | openssl s_client -connect example.com:443 -verify_return_error 2>/dev/null && echo "OK" || echo "CHAIN BROKEN"