SSL Certificate Chain Checker

Subject

Issuer

About Certificate Chain Validation

A certificate chain is the ordered list of certificates from the leaf (server) certificate up to a trusted root CA. An SSL certificate chain checker fetches the chain a server actually presents. Our Certificate Chain Validator fetches the chain presented by a server, checks its completeness, verifies expiry dates, identifies missing intermediate certificates, and confirms whether the chain builds correctly to a trusted root. Proper chain validation is essential for browser trust and preventing certificate errors.

How to Use

Enter the domain name of the server whose certificate chain you want to validate.
Click Validate to fetch and analyze the certificate chain.
Review the chain validity status and total number of certificates in the chain.
Check any reported issues for details on missing intermediates or expired certificates.

Use Cases

Certificate Installation: Verify that your server is serving the complete certificate chain after installation.
Troubleshooting: Diagnose browser certificate errors caused by missing intermediate CA certificates.
Renewal Verification: Confirm that renewed certificates have valid chains before deployment.
Compliance Auditing: Document certificate chain structures for security compliance requirements.

Frequently Asked Questions

Incomplete chains occur when the server does not serve the intermediate CA certificate along with the leaf certificate. Browsers may still work if they have cached the intermediate, but visitors without the cached intermediate will see certificate errors. Always include all intermediate certificates in your server configuration.

Most typical chains contain 2-3 certificates: the leaf (server) certificate, one or more intermediate CA certificates, and optionally the root CA certificate. Root CA certificates are often omitted since browsers already trust them. The validator will show the exact count for your server.

Yes. A chain may be technically valid but still trigger browser warnings if the leaf certificate uses SHA-1, has an expired or not-yet-valid date, uses a hostname mismatch, or if the certificate has been revoked. Use our SSL Certificate Checker for comprehensive server validation.

Each certificate is signed by the one after it. The first is the leaf for your hostname, the next is the issuer of that leaf, and so on until you reach a self-signed root. If certificate 2's subject does not equal certificate 1's issuer, the link is broken and the chain will not verify. Missing intermediates are by far the most common problem, because a server will happily serve the leaf alone even though it has the rest of the file on disk.

Concatenate the leaf first, then each intermediate in order, into one file — cat server.crt intermediate1.crt intermediate2.crt > fullchain.pem — and point the server at that file. Nginx takes it in ssl_certificate; on Apache 2.4.8 and later put the chain in SSLCertificateFile. Then confirm with openssl s_client -showcerts and count the certificates.

Your machine has an intermediate cached from a previous connection, or trusts a private CA that the public web does not carry. The validator here follows the chain the server actually sends and compares it against the public trust store, which is what a stranger's browser does. It is also common for an internal hostname to terminate TLS with an internal certificate while the public name is served correctly, so always test the exact public hostname.

No. Roots are self-signed and every client already carries them, so including one adds nothing but bytes and is occasionally flagged as a misconfiguration. Send the leaf plus any intermediates and stop there. If a client cannot build the path, the answer is a missing intermediate, never a missing root. Some certificate authorities do publish a cross-signed intermediate to work around older root distrust, and that is an intermediate to send, not a root.

Rarely, but it happens. Some clients and middleboxes cap the number of certificates they will accept in one handshake, and an over-long chain is truncated, which produces the same unable to get local issuer error as a short one. Real-world chains are three to five certificates: leaf, one or two intermediates, then the root held by the client. If yours is much longer, it usually means an intermediate was concatenated twice.

How to Fix an Incomplete Chain

An incomplete chain shows up as unable to get local issuer certificate in OpenSSL, or a warning icon in the browser address bar. The server is sending the leaf certificate but not the intermediates that link it to a trusted root.

1. Build the chain in the right order

Concatenate the leaf first, then each intermediate, one after another. Never include the root — clients already have it.

cat server.crt intermediate1.crt intermediate2.crt > fullchain.pem

2. Point the server at the full chain

Nginx: ssl_certificate /etc/nginx/ssl/fullchain.pem; — the file must be the full chain, not just the leaf.

Apache 2.4.8+: put the chain in SSLCertificateFile. SSLCertificateChainFile is deprecated.

IIS: import the intermediates into the server certificate store; IIS serves whatever is in the store.

3. Confirm what is actually being sent

openssl s_client -connect example.com:443 -servername example.com -showcerts

Count the certificates in the chain and compare their subjects with the issuers listed in each one. A missing link shows up as a subject that does not match the next issuer.

Still short? The chain is usually truncated at the TLS handshake if the server has more intermediates than it can send in one message — a missing file on disk is the more common cause. Check the file the server is actually configured to load before reloading.

Technical Details

Validation: Complete certificate chain trust validation
Trust Stores: Mozilla, Apple, Microsoft, and Google trust stores
Checks: Chain completeness, expiry, revocation, and signature verification
Output: Validation report with trust status and issues