Expiry
The obvious one, and the easiest to automate away. Most certificates now last ninety days precisely so that renewal has to be automatic.
A certificate can be expired, not cover the name asked for, not chain to a trusted root, or be perfectly fine while the server still accepts protocol versions browsers refuse. This checks all four, and deliberately turns verification off first so a broken certificate can be described rather than refused.
The obvious one, and the easiest to automate away. Most certificates now last ninety days precisely so that renewal has to be automatic.
A certificate is valid for the names in it. A wildcard covers exactly one label in the leftmost position — *.example.com does not cover example.com itself.
Servers must send their intermediate certificates, not just their own. Clients that happen to have the intermediate cached will work anyway, which is why this fault looks intermittent.
Each is probed on its own connection, so “TLS 1.0 accepted” is a measured fact about the server rather than an inference from one handshake.
A certificate authority does not sign your certificate with its root key. It signs with an intermediate, and that intermediate is signed by the root. A client therefore needs all three to build a chain — and your server is responsible for sending the first two.
When the intermediate is missing, something strange happens: the site works for most people. Browsers cache intermediates they have seen before, and many have seen yours from some other site. So the site works on your laptop, works for your colleagues, and fails for a customer on a fresh device or an API client with no cache at all. The reports come in as "it works for me" and get closed.
This checker reports the one-certificate case specifically, because the generic message — "the chain does not verify" — sends people to reissue a certificate that was never the problem. The fix is a server configuration change: install the full chain file the authority provided, not just the leaf.
On protocol versions, the thing worth knowing is that disabling TLS 1.0 and 1.1 now costs almost nothing. Every browser removed support in 2020, so anything still requiring them is not a browser. Leaving them on does not help those clients reach you — it just leaves the older constructions available to anything that wants them.
The three most likely causes, in order: the chain is incomplete and the visitor's client has no cached intermediate; the certificate does not cover the exact name typed, often www versus the bare domain; or something on the page is loaded over plain HTTP. This checker covers the first two directly.
No. A wildcard replaces exactly one label and only the leftmost one, so *.example.com covers www.example.com and api.example.com, and does not cover example.com itself or a.b.example.com. Certificates for a bare domain and its subdomains list both names explicitly.
Yes, in almost every case. Browsers removed support in 2020, so leaving them enabled does not keep any real visitor working — and they fail a PCI DSS assessment. The exception is an API with known old embedded clients, and then the right move is to find out what those clients are rather than leave the versions on indefinitely.
Because refusing to would make it useless. A tool whose job is to tell you your certificate is broken cannot decline to connect to broken certificates — so verification is switched off deliberately, and then what verification would have said is reported.
Monitor it rather than check it. Certificate expiry is the most predictable outage there is, and the useful thing is an alert thirty days out, not a page someone remembers to visit. This tool is for diagnosing a specific problem.
An expired certificate, a missing header or an exposed port is a finding. Knowing which of them matters on your estate, fixing them without breaking the application, and noticing the next one before a stranger does is the work. That is what we do, continuously rather than as a report.