Free tool · no signup

Does your certificate chain actually validate?

See exactly what your server sends, whether a strict client trusts it, what is missing and how to fix it — the same verdict a PylonMon monitor gives.

Hostname or host:port. We connect from the public internet and never store what we see.

Monitor this domain freeFree for your first domains. We check the chain three times a day and page you 14 and 3 days before expiry.

“Works in Chrome, fails in curl” — the incomplete chain

A browser that hits a certificate it cannot chain to a root will quietly fetch the missing intermediate itself (AIA fetching). Go, curl on Linux, Python, Java, mail servers, monitoring agents, smart TVs and most phones will not: they trust exactly what your server sends, and if the path stops one certificate short, the connection fails with certificate signed by unknown authority or unable to get local issuer certificate. Your site looks fine to you and is broken for a large share of real clients.

In 2026 this got common. Let’s Encrypt’s new roots (ISRG Root YE and Root YR, behind the YE1/YR1 intermediates) are not in most trust stores yet, so the default chain includes a third certificate: the new root cross-signed by ISRG Root X1. A server that only sends the leaf and the intermediate is exactly one certificate short.

How to fix it

NGINX

Serve the full chain

ssl_certificate must point at fullchain.pem, not cert.pem. Then nginx -s reload.

APACHE

Same file, one directive

Point SSLCertificateFile at fullchain.pem (Apache 2.4.8+); older versions need SSLCertificateChainFile.

CADDY · TRAEFIK · CERTBOT

Usually already right

Automatic ACME clients serve the full chain. If you copied files by hand, copy fullchain.pem. Certbot: --preferred-chain picks which chain you get.

Then run the check again. When the last certificate the server sends is issued by a root every client already trusts, the verdict turns green.

The other verdicts

Self-signed — the certificate signs itself. Fine for a lab; every public client refuses it.
Private CA — the chain ends at a root only your own machines trust.
Expired / not yet valid — the dates on the leaf are wrong for today (or the server’s clock is).
Hostname not covered — the certificate is for other names. Common with an IP-address target or a cert issued for a different subdomain.

Check it every day, not once

A chain that validates today breaks on the next renewal that copies the wrong file, the next CA root rotation, or the next intermediate reissue. A PylonMon SSL certificate monitor re-runs this exact check from outside your network three times a day, records days-to-expiry, and pages you when the chain stops validating — with the same explanation you see above, not a library error. Start free.