Check a site's SSL/TLS certificate

A certificate can be current, from a well-known authority, and still fail, because trust is a chain rather than a single file. The server has to send the intermediate certificate alongside the leaf; without it a client has nothing to link the certificate to a root it already trusts, and verification fails on a certificate that is otherwise perfectly good.

This is the misconfiguration that survives longest, because the audience most likely to notice it cannot. Browsers paper over it: they fetch the missing intermediate from the address inside the certificate, and they reuse intermediates cached from other sites. So the site looks correct to the person checking it, while API clients, payment callbacks, older Android devices, and server-to-server calls fail against the same address.

The report separates this from an untrusted authority, because the fixes are opposites. An incomplete chain is fixed by serving the full chain (`fullchain.pem` rather than the leaf alone); buying another certificate changes nothing, since the certificate was never the problem.

So the finding names the certificate at fault rather than the authority. The report walks the chain the server presented, verifying each link by signature rather than by matching names, and reports where it stops: which certificate was reached last, which one was never sent, or which link was signed by something other than the certificate offered for it. An intermediate that has expired is called out separately, because the site's own certificate is then still valid and replacing it would fix nothing.

Under the Security axis, "TLS certificate validity". A healthy site shows PASS with "Valid; expires in N days", and the exact expiry date and issuer in the evidence chip. An expiring certificate is flagged before it lapses, so a renewal can happen ahead of an outage; an invalid one caps the score.

The evidence chip carries the facts of whatever decided the verdict, which is not always the date. A chain failure draws the chain as far as it could be verified and marks where it stops, naming the certificate that was never sent; a hostname failure lists the names the certificate actually covers. On those verdicts the expiry date explains nothing, so it is not what the chip shows.

The certificate is always judged on the domain that was entered, even when it redirects elsewhere. A site whose apex serves a broken chain and redirects to a working www host fails here, because that apex is what a visitor reaches first, and the report says which host the finding belongs to.

• Renew before expiry, and automate it (certbot or another ACME client) so it never lapses.
• Make sure the certificate covers the exact hostname served, including the www or bare-domain form visitors actually reach.
• Serve the full chain, intermediate included, not just the leaf certificate. Where that chain lives depends on the stack: an ACME client such as certbot writes it to fullchain.pem, Apache takes it via SSLCertificateChainFile, a hosting control panel usually has a separate CA bundle field, and IIS expects the intermediate imported into the certificate store.
• Verify: re-scan and confirm the new expiry date.

How early does the scan warn before a certificate expires?

At 30 days. Inside that window the check turns WARN and names the remaining days, which is enough time for a renewal to be a scheduled task. An expired certificate is a FAIL and caps the overall score at 50, because browsers show a full-page warning that stops most visitors.

Does a free certificate score lower than a paid one?

No. The check reads validity, expiry, hostname coverage, and whether the chain verifies. A free Let's Encrypt certificate that renews automatically passes exactly like a paid one, and its 90-day lifetime with auto-renewal is a common reason sites stop failing this check at all.

The certificate works in the browser but the scan reports a chain problem. Why?

Because browsers hide it. Many of them fetch a missing intermediate certificate on their own, so a server that sends an incomplete chain still looks fine in a desktop browser while failing for API clients, payment callbacks, and older mobile devices that do not fetch anything. The fix is serving the full chain from the server.

Does the certificate need to cover both www and the bare domain?

It needs to cover every hostname visitors actually reach, and both forms usually qualify. A certificate issued for one but not the other produces a hostname mismatch on the missing form, which browsers treat as a hard error rather than a warning.

• HTTPS & HTTP→HTTPS redirectA valid certificate still leaves plain HTTP open unless a redirect closes it, and that gap caps the score at 40.
• Mixed contentWhat still costs the padlock once the certificate itself is in order.