Build and validate X.509 certificate chains from your certificates
Building certificate chain...
Chain Structure
| Issuer:
Self-Signed
Full Chain PEM
About Certificate Chain Builder
Our free Certificate Chain Builder constructs and validates SSL certificate chains. Paste server and intermediate certificates to build the complete chain, verify its correctness, and identify any missing or expired certificates in the chain.
How to Use
1Paste the server certificate in the first field.
2Paste intermediate certificates (one per PEM block) in the second field.
3Click "Build Chain" to construct and validate the certificate chain.
Use Cases
•Debug SSL chain errors
•Verify intermediate certificate installation
•Validate complete chain before deployment
•Troubleshoot "unable to verify certificate" errors
Chain problems are usually ordering problems: the right certificates are present but in the wrong sequence, so a client cannot build a path. This page takes the certificates you paste and puts them in the right order.
1Parse every pasted certificate and index it by subject and issuer distinguished name, so the relationships between them can be followed rather than inferred from order.
2Identify the leaf as the certificate that is not self-signed, then walk upward from it, matching each certificate's issuer to the next one's subject until a self-signed root is reached. Any certificate not reached by that walk is an intermediate you are missing.
3Report completeness and the ordered chain. Each certificate's subject, issuer and self-signed status is shown, so you can see exactly where the sequence stops and what has to be added.
Export is available as PEM, which is what servers consume. PFX is not offered and the page says why: a PKCS#12 bundle must contain the private key, which this builder never receives — it only handles public certificates.
Tips & Best Practices
•Always include all intermediate certificates from your CA
•Server certificate goes first in the chain
•Test the complete chain before deploying to production
Frequently Asked Questions
Because the server is sending only the leaf and the intermediates are missing. This is the single most common certificate fault and it is easy to miss, because a server with only its leaf certificate configured starts perfectly happily and works for anyone whose machine happens to have cached an intermediate from a previous visit. The fix is to concatenate the leaf first, then each intermediate in order, into one file and point the server at that rather than at the certificate it emailed you.
The server's own certificate first, then each intermediate in order, working outward from the certificate that issued your server certificate towards the root. The order is not arbitrary: each certificate in the file is the issuer of the one before it, so a reader walking the file expects that relationship at every step. The root itself is not sent, because clients already hold it. If you concatenate in the wrong direction the path will not build even though every certificate is present and correct.
In practice one or two, which is what almost every authority uses. There is no hard limit, and some private authorities run deeper hierarchies, but every extra level adds bytes to every handshake and another signature for the client to verify. Very deep chains are also the most likely to exceed what some clients will accept in one handshake, and the resulting truncation looks exactly like a short chain. If your chain is longer than about five certificates, look for a repeated intermediate before assuming the hierarchy is intentional.
Because validity is per certificate while trust is about the path. A client must build a chain from your certificate up to a root it trusts, and it can only do that if each link's issuer matches the next certificate's subject. Serving the right certificates in the wrong order breaks that walk, as does omitting an intermediate entirely. Validity checking on each file individually will not catch either problem.
The builder's walk shows where the sequence stops. If your leaf's issuer names an authority that is not present among the pasted certificates, that authority is your missing intermediate, and you can find it from the authority's own site. The failure also reproduces predictably: some clients will still validate because they cache intermediates, which is why an incomplete chain can appear to work until a fresh client connects.
Because a PFX bundle must contain the private key, and this tool only ever receives public certificates. Producing a PFX without the key would be useless, and pretending otherwise would be worse. Export PEM, which is what web servers consume, and keep the key in its own protected file where it belongs.
No — it guarantees a connected one. Completeness means every link is present so the path can be built; validity additionally requires that each signature verifies, that the root is one clients trust, and that every certificate is within its validity window. Use the trust verification page for that second question, and run both.
Almost never. Clients already hold roots, and sending one in the chain is at best redundant. What a server should serve is the leaf plus any intermediates needed to reach a root the client already has — omitting the root is correct and sending it is at best pointless. The exception is pinning scenarios, where serving a pinned intermediate is deliberate.
