Analyze the depth and structure of SSL/TLS certificate chains
Chain Analysis
Chain Depth
Number of certificates in the chain
About Certificate Chain Depth Checker
Analyzes the depth of certificate chain hierarchies and identifies optimal intermediate certificate paths. Checks for chain length issues that cause validation failures.
How to Use
1Enter the domain name you want to analyze.
2Click "Analyze Chain" to retrieve and inspect the certificate chain.
3Review the chain depth, hierarchy, and validity status of each certificate.
Use Cases
•Validate chain completeness before deploying certificates
•Optimize certificate delivery by reducing chain depth
•Debug trust issues caused by missing intermediate certificates
Frequently Asked Questions
Chain depth refers to the number of certificates in the trust chain from the end-entity certificate to the root CA. A typical chain includes the server certificate, one or more intermediate certificates, and the root certificate.
Most browsers support chains up to 10 certificates deep, but a depth of 3-4 (root, intermediate, server cert) is recommended for optimal compatibility and performance.
Deeper chains increase the amount of data sent during the TLS handshake, adding latency. They also increase the chance of validation errors if any intermediate certificate is missing or expired.
It is worse for performance and no better for security, so in practice yes. Each extra certificate has to be transferred and its signature verified before the handshake completes, and on a high-latency connection that is real time a visitor waits. Depth buys nothing: the chain exists only to link the leaf to a root the client already trusts. What matters is that the required intermediates are present, not that there are more of them.
Almost always because two files were concatenated and both already contained it. This is the usual outcome of building a chain by appending whatever the certificate authority emailed, when two of those emails covered overlapping intermediates. The result still validates on many clients because they skip a certificate they have already seen, but it is worth fixing: it adds bytes to every handshake, and some clients cap how many certificates they will accept and truncate beyond that, which produces an error identical to a short chain.
Not any more. Older clients fetched missing intermediates using the Authority Information Access extension, which is why a leaf-only configuration used to work for anyone who had visited before. That behaviour was removed, precisely so that a server could not rely on a cache it does not control. A first-time visitor on an empty cache now fails outright, which is why a chain that appears to work in testing can be broken in production.
No. Roots are self-signed and every client already holds them, so sending one adds bytes and achieves nothing. What to send is the leaf plus the intermediates that link it to a root. Some authorities publish a cross-signed intermediate to work around distrust of an older root — that is an intermediate and should be sent, which is a different thing from including the root itself.
Three in the ordinary case: the leaf, one intermediate, and the root the client holds rather than receives. A few authorities use two intermediates, making four. Treat anything beyond about five as a signal to look for a duplicated certificate rather than assuming a deep hierarchy is intentional, since a legitimate hierarchy that deep is rare and the duplicate is a common and easy mistake.
How Depth Is Measured
Chain depth is simply how many certificates the server sends. It is worth measuring because it is one of the few TLS costs you can reduce without any behavioural change.
1Connect and read every certificate the server presents, not just the first. Servers vary widely in whether they send intermediates, and that is the thing being measured.
2Count the certificates in the handshake. That count is the depth.
3Compare against a recommended maximum of three, which covers the leaf, one intermediate and one spare. Anything beyond that is flagged.
A count of one is the finding to watch for: it means no intermediates were sent, and any client without a cached copy cannot build a path to a root. A count that is unexpectedly high usually means a certificate was concatenated twice.
Tips & Best Practices
•Aim for certificate chains with 2-3 certificates total (leaf + 1-2 intermediates)
•Avoid chains longer than 4 certificates as they impact performance
•Use chain depth analysis to identify unnecessary intermediates
•Optimize chain depth for better TLS handshake performance
Technical Details
Depth: Certificate chain length measurement Analysis: Chain optimization recommendations Performance: Impact of chain depth on handshake time Output: Chain depth assessment with optimization suggestions
