SSL certificate checker

What this tool does

Connects to the host over TLS and reports what the server actually presented: the certificate's subject, its issuer, the validity window, the names it covers, the protocol that was negotiated, and whether the chain served alongside it is complete.

It checks from outside, which is the point. A certificate can be installed correctly on disk and still be served wrongly — the wrong file, a stale copy on one node behind a load balancer, an intermediate the web server was never told to include. The only way to know what visitors get is to ask the way a visitor does.

Covered names, and why www matters

A certificate is valid for the names listed in it, and nothing else. Those live in the Subject Alternative Name list — the SANs. The older Common Name field is still shown by most tools, including this one, but browsers stopped relying on it years ago; if a name is not in the SANs it is not covered, whatever the Common Name says.

This is where the apex and www catch people. They are different names and each needs to be listed. A certificate issued for example.com alone will throw a full-page browser warning on www.example.com, even though the site works and the certificate is perfectly valid. The fix is usually not a second certificate but picking one as canonical and redirecting the other — and making sure the certificate covers both, because the redirect itself happens over HTTPS.

A wildcard such as *.example.com covers one level only. It matches www.example.com and api.example.com, and it does not match example.com itself or a.b.example.com.

The chain, and what a missing intermediate breaks

Your certificate is not trusted on its own. It is signed by an intermediate, which is signed by a root, and only the root is in the client's trust store. The server is expected to send the intermediates along with the certificate so the client can build the path. Roots are not sent; the client already has them.

When an intermediate is missing, the result is the worst kind of bug: it works for most people. Browsers quietly fetch the missing piece themselves, or have cached it from another site that served it properly, so the site looks fine to you and to everyone who tested it. The clients that do not do that — command-line tools, payment callbacks, mobile apps, older systems, anything doing a webhook — fail outright.

So "the chain is incomplete" here while your browser shows a padlock is not a contradiction, and it is not something to dismiss. What TLS is actually doing has more on why.

Expiry, and when to act

Days remaining under fourteen means renewal should already have happened. Automated issuers such as Let's Encrypt renew at thirty days precisely so that two weeks of failures can go unnoticed without anything breaking, and certificate lifetimes have been getting shorter across the industry rather than longer — which makes automation less optional every year.

An expired certificate is not a soft failure. Browsers refuse the connection with an interstitial most visitors will not click through, and automated clients simply stop. There is no grace period and no warning to visitors beforehand.

If renewal is automated and the date here is not moving, the renewal is running and the new certificate is not being served. Look at whether the service was reloaded after the file changed — that is the usual answer — and whether every node behind a load balancer got the new file.

Common problems

A mixed-content warning is a page problem, not a certificate problem. The certificate is fine; something on the page is loading an image, script or stylesheet over plain HTTP, and the browser is objecting to that rather than to your TLS.

If issuance is failing rather than serving, check for a CAA record on the domain. It names which certificate authorities are allowed to issue for you, and an old one naming an authority you no longer use will block the one you do.

A self-signed certificate is neither refused here nor flagged. This tool reports what the server presented rather than passing a verdict on it, so there is no trusted or untrusted row to look for — you recognise one by reading the rows: the same name as both subject and issuer, and a chain of leaf only, which for a self-signed certificate is expected rather than the missing-intermediate fault described above. An internal host usually cannot be checked from here at all, because any name that resolves to a private address is refused by design.