Verify your certificate chain resolves to a trusted root.
Runs against a live TLS connection or the certificate you paste in — nothing here is stored or sent anywhere else.
It connects to your domain, collects every certificate the server sends during the handshake, and lists them in order. Separately, it attempts a fully verified connection to determine whether that chain actually resolves to a trusted root.
Those are two different questions, and the gap between them is where most chain problems live. A server can present a perfectly valid certificate and still fail verification because it never sent the intermediate that links that certificate to a root.
You install a certificate, load the site in your browser, see a padlock, and move on. What you did not see is that your browser already had the intermediate cached from some other site that uses the same certificate authority, or quietly fetched it using the URL in the certificate's authority information access extension.
Other clients are stricter. curl, wget, Python's requests, Java's default trust manager, Go's crypto/tls, and many mobile and embedded HTTP stacks verify only what the server hands them. The result is a failure mode that looks impossible from the outside: the website works, but the API integration, the webhook delivery, or the mobile app cannot connect.
This is also why "it works on my machine" is unusually misleading for TLS problems. The browser is the least strict client you own.
A correctly configured server sends its certificates in order, from the leaf outward:
Each certificate's issuer should match the next certificate's subject. Where that link is missing, the chain is broken there.
Your certificate authority supplies the intermediates, usually as a separate "CA bundle" or "chain" file in the same download as your certificate. The fix is to serve them together.
nginx expects one file containing the leaf followed by the intermediates:
cat example.com.crt intermediate.crt > fullchain.crt
# nginx.conf
ssl_certificate /etc/ssl/certs/fullchain.crt;
ssl_certificate_key /etc/ssl/private/example.com.key;Apache with mod_ssl 2.4.8 or later reads the chain from the same file:
SSLCertificateFile /etc/ssl/certs/fullchain.crt
SSLCertificateKeyFile /etc/ssl/private/example.com.keyIf you use an ACME client such as Certbot, this is handled for you — point your server at fullchain.pem rather than cert.pem. Pointing at cert.pem is the single most common way to end up here.
To check from a terminal, this shows the chain a server sends and stops at the first verification failure:
openssl s_client -connect example.com:443 -servername example.com -showcerts < /dev/nullCertificate authorities rotate their intermediates, and a renewal can quietly move you to a new one. If your deployment copies a chain file that was correct two years ago, verification can start failing on a renewal that otherwise looked routine.
Renew Radar re-checks the full chain on every sweep, not just the expiry date, so a chain that breaks after a renewal shows up as an alert rather than as a support ticket. Free while in beta for up to 20 certificates.
Your certificate is signed by an intermediate certificate, which is signed by a root certificate that is already in the client trust store. That sequence is the chain. A client will only trust your certificate if it can follow every link, and your server is responsible for sending the intermediate links.
A server that sends its own certificate but not the intermediates above it. Desktop browsers often hide the problem because they cache intermediates from other sites or fetch them on the fly. Command-line tools, mobile apps, Java clients, and payment gateways generally do not, so they fail while your browser looks fine.
This is the classic symptom of a missing intermediate. Chrome has probably seen your CA intermediate before and reuses it; curl starts from nothing every time and can only verify what your server actually sends. Fix the server configuration rather than passing -k.
Concatenate your certificate and the intermediates your CA supplied into one file, leaf first, and point your server at that. On nginx this is the ssl_certificate file; on Apache it is SSLCertificateFile with mod_ssl 2.4.8 or later, or SSLCertificateChainFile on older builds.
No. The client already has the root in its own trust store, and sending it adds bytes to every handshake for no benefit. Send the leaf and the intermediates, and stop there.
Yes. The leaf certificate must come first, then each intermediate in order toward the root. Some clients tolerate a wrong order and some reject it outright, so it is not worth relying on leniency.