SSL Certificate Chain Checker

Check the entire certificate chain served directly from the server. From the leaf up to the root CA. Find out if it's valid, or if it's missing intermediates, has hostname mismatches, expired certificates, untrusted roots, weak keys or other problems.
  • Enter a hostname, a URL, or host:port. CertKit's servers connect to it, record exactly which certificates it sent in the TLS handshake, and build the chain the way a browser would.
  • Only publicly reachable hosts can be checked. For servers inside your network, use CertKit's monitoring agent.
  • Checks are limited to 10 per hour per visitor. Need more? Create a free account.
certkit.io missing intermediate expired wrong hostname self-signed

What is an SSL certificate chain?

An SSL certificate chain, also called the chain of trust, is the sequence of certificates that links a server's certificate to a root certificate the client already trusts. The chain starts with the leaf certificate, the one issued for your hostname. The leaf is signed by one or more intermediate CA certificates, and the intermediate is signed by a root CA certificate. Roots are included with the browser or operating system. Each signature proves that the certificate above issued the one below, and a client validates the chain by walking it in order, from leaf to intermediate to root.

When a server leaves out an intermediate, the failure shows up unevenly. A browser may load the site fine while curl or a mobile app fails with unable to get local issuer certificate or unable to verify the first certificate. This checker shows the exact chain your server sends and where it breaks.

What to use this tool for

A TLS server is supposed to send its own certificate plus every intermediate CA certificate needed to reach a root the client already trusts. When it doesn't, or when something in that chain is wrong, the result is the familiar "your connection is not private" page in browsers. This checker looks for:

  • Incomplete chains. The server only sends the leaf certificate and relies on clients to download the intermediate from the AIA URL. Chrome and Windows sometimes do, but Android, Java, Python, curl and most embedded devices don't.
  • Hostname coverage. Whether the name you typed is in the certificate's Subject Alternative Names, including wildcard rules (*.example.com does not cover example.com).
  • Validity periods. Expired or not-yet-valid certificates anywhere in the chain, certificates expiring soon, and leaf lifetimes over the 398-day browser limit.
  • Trust. Whether the chain ends at a publicly trusted root, a private CA, or a self-signed certificate.
  • Chain hygiene. Stale intermediates from an old certificate still being sent, the root certificate being sent unnecessarily, certificates sent out of order.
  • Keys and signatures. RSA keys under 2048 bits, SHA-1 or MD5 signatures, missing serverAuth extended key usage, a CA certificate used as a server certificate.

For every certificate in the chain you also get the SHA-256 and SHA-1 fingerprints, serial number, key algorithm and size, signature algorithm, validity dates, AIA and CRL links, the PEM, and a link to the issuing CA's published root and intermediate certificates.

How to fix an incomplete chain

Your CA gave you (at least) two files: the certificate itself and one or more intermediates, often bundled as fullchain.pem, ca-bundle.crt or similar. The server needs to be configured with the bundle, not just the certificate. In nginx that's ssl_certificate fullchain.pem;; in Apache it's SSLCertificateFile pointing at the full chain (or SSLCertificateChainFile on older versions); on Windows the intermediate needs to be in the computer's Intermediate Certification Authorities store. Re-run the check after reloading the server.

More useful tools