Certlens
SSL certificate checker
The incomplete chain, and why it looks fine to you
A certificate is trusted by way of a chain: your certificate is signed by an intermediate, which is signed by a root that browsers already trust. The server is supposed to send its own certificate and the intermediates, so a client can build that path.
Servers that send only their own certificate frequently appear to work. Browsers cache
intermediates they have seen before, and some fetch missing ones automatically — so the
person who set it up loads the site, sees a padlock, and moves on. Meanwhile every API
client, every mobile app, every curl in a deployment script and every
device that has not encountered that intermediate fails with a verification error.
That is why the chain length is reported here. One certificate for a publicly signed site is worth investigating.
Names, wildcards, and the mismatch warning
Which names a certificate covers comes from its Subject Alternative Name list, not from
the common name — that has been deprecated for years, though it is still displayed.
A wildcard such as *.example.com matches exactly one label: it covers
www.example.com, but neither example.com itself nor
a.b.example.com.
The apex omission is a common and confusing failure — a wildcard certificate that serves the whole site perfectly except the address people actually type.
What a check here does and does not tell you
This connects the way a browser does, with SNI, and reports whether verification against the public trust store succeeds. If it fails, it connects again without verification so you can still see what is being served — because a broken certificate is exactly what you came to look at, and a tool that refuses to show you is useless at the moment it matters.
It does not grade cipher suites, test for protocol vulnerabilities, or scan configuration in the depth a dedicated TLS analyser does. If you need that, run one — this is for the two questions that account for most real outages: is it about to expire, and is the chain complete.
Expiry is an operational problem, not a security one
Certificate lifetimes have been shortening for years, and automated renewal is now the norm rather than a convenience. Nearly every expiry outage is a renewal job that stopped working quietly weeks earlier — a changed API token, a firewall rule, a validation record removed during unrelated cleanup.
Checking the certificate tells you the deadline. Checking that the renewal still runs is the thing that actually prevents the outage, and it is worth a calendar reminder well before the expiry date rather than on it.
This tool uses the util.quest server. It cannot run in your browser — the work is either impossible there or too heavy for it. What you submit is sent to this server, used to produce the result, and not stored afterwards. Requests are rate limited, and nothing about them is logged beyond what is needed to enforce that.
Inspect the TLS certificate a site actually serves: issuer, validity dates, subject alternative names and the full chain as presented. Catches the two failures that take sites down — a certificate about to expire, and an incomplete chain that works in your browser because it cached the intermediate and fails everywhere else.
It's one of the free tools in the util.quest collection — nothing to install, and no account needed. Found a bug or want a feature? Reach out at [email protected].
