Missing intermediate certificate checker

What a certificate chain contains

A TLS server normally presents its leaf certificate followed by the intermediate certificates that connect it to a trusted root authority. The leaf certificate identifies the hostname, while an intermediate is a certificate authority allowed to issue leaf certificates. The root is usually already installed in the client trust store, so servers commonly omit it. Clients verify each signature and hostname, then stop when they reach a trusted root.

A server can therefore hold a perfectly valid leaf certificate and still be misconfigured. If it sends only the leaf when an intermediate is required, a strict client cannot build a path from that certificate to one of its trusted roots. The missing link is not necessarily a problem with the certificate itself; it is often a problem with the chain delivered during the handshake.

Why browsers may work while Java clients fail

Some browsers can recover from an incomplete chain by using an intermediate certificate cached from an earlier visit or by fetching one from the Authority Information Access (AIA) URL embedded in a certificate. That behavior can hide an origin configuration problem. Other clients do not fetch AIA certificates, may run without network access to the certificate authority, or may intentionally restrict trust-path discovery.

Java applications often report PKIX path building failed or unable to find valid certification path to requested target when the chain cannot be constructed from the certificates available to the JVM. Python clients may report unable to get local issuer certificate. Mobile SDKs and older operating systems can have different trust stores and caching behavior, so a browser check alone is not enough to prove every client will connect.

How this missing intermediate certificate checker works

This free TLS chain debugger connects to the public HTTPS hostname you enter, captures the certificates presented by that endpoint, and compares the presented path with the local trust store. It shows safe certificate metadata—subject, issuer, validity dates, and a SHA-256 fingerprint—so you can see which certificate is missing or out of order. It also reports OCSP stapling and whether CAA records are present.

The checker does not use a browser cache to fill in missing certificates. It inspects the server-presented chain and does not fetch issuer certificates from AIA. This makes it useful for finding the kind of chain problem that only appears in a clean runtime or a client with a different trust store. A result is a diagnostic signal, not a substitute for testing the same runtime and network used by your production clients.

How to fix an incomplete TLS chain

Configure the web server, ingress controller, load balancer, or certificate manager to serve the leaf certificate together with every required intermediate. Many certificate providers supply a “full chain” bundle for this purpose. For Nginx, the configured certificate file should normally contain the leaf first and the intermediate certificates after it; Apache, Caddy, cloud load balancers, and Kubernetes ingress controllers have equivalent chain or bundle settings.

Avoid adding a root certificate to the served chain unless your provider explicitly requires it. Confirm the intermediate belongs to the certificate authority that issued the leaf and that the order follows issuer-to-subject relationships. After updating the configuration, reload the service safely, inspect the endpoint again, and test from a clean JVM or container that does not have the intermediate cached.

Inspect the chain with OpenSSL

OpenSSL can show what a host presents on a particular port. Use the hostname for both the connection and SNI so a virtual host returns the same certificate chain your client receives:

openssl s_client -connect api.example.com:443 \
  -servername api.example.com -showcerts -verify_return_error </dev/null

Review the verification result and the certificates between the PEM boundaries. If you have the leaf and intermediate files locally, you can also verify the leaf against the issuer bundle. Compare the command output with the chain shown above, and remember that a successful connection from one machine does not prove that every production trust store contains the same roots.

Common deployment mistakes

• Installing a leaf-only certificate instead of the provider’s full-chain bundle.
• Updating the application container while TLS terminates at a separate proxy or load balancer.
• Serving a certificate for the wrong hostname because SNI or virtual-host routing is misconfigured.
• Updating one region or replica while another still serves an older chain.
• Rotating certificates without reloading the process that owns the listening TLS socket.
• Testing a browser that already cached the missing intermediate and treating that result as universal.

If only some requests fail, compare the certificates and fingerprints returned by each public address or region. A CDN, anycast service, or load balancer can route clients to different backends. Certificate deployment should be consistent across every termination point, and the health check should exercise the public hostname rather than only an internal origin address.

Prevent the same outage from returning

A one-time check is useful during an incident, but certificate chains change during renewals, CDN migrations, and infrastructure updates. Monitor the public endpoint on a schedule and alert on chain failures before customer traffic reaches a runtime that cannot recover. Include hostname validation and certificate expiry in the same operational review, and keep the alert tied to the exact endpoint clients use.

SteadyNode monitors HTTPS endpoints and TLS health checks every six hours, then alerts your team when a public service stops meeting its expected availability signals. Use this debugger to investigate the current chain, then add continuous monitoring so a later renewal or load-balancer change does not silently reintroduce the missing intermediate.