Which host is that finding about?

By Matt Kerr·Published 18 September 2026

An audit tells you your certificate expires in a fortnight. You check, and it has months left. You conclude the tool is broken and stop reading — which is the worst outcome available, because the finding was right about a host you did not check.

Almost every security finding is about one address, and there are usually several that all look like your site: the bare domain, the www spelling, whatever they redirect to. A finding that does not say which one it measured invites you to disprove it against the wrong one.

The certificate on the host you redirect to

An audit of a streaming service was started at its www address. Every page redirected to a different host, and it was that host's certificate that was close to expiry. The finding said the certificate expires soon and named nothing. Checking the address that had been typed shows a comfortable margin, so the sentence reads as plainly false.

The person who wrote the check records making exactly that mistake, with exactly that evidence, before thinking to follow the redirect. That is worth saying because it is the ordinary response: a claim you can falsify in ten seconds is one you stop investigating.

Naming the host is the entire fix, and it is all that is available — once a crawl has followed a redirect, the address you typed is gone, and the tool genuinely cannot tell you what you asked for. Which produced a second lesson in the same commit: the first repair added a sentence saying "you asked for this address, which redirects here", and that branch could never run. A sentence that cannot fire is worse than no sentence, because it looks like coverage.

The spelling that redirects and the spelling that does not

The same shape, one layer down. An audit of a bakery chain began at the www spelling, where the plain-http address answered without redirecting to https. True, and reported at high severity — with no host named and no evidence attached.

The apex redirects correctly. So the owner reads the finding, types the bare domain, watches it redirect to https exactly as it should, and concludes the tool is wrong about something it is right about.

The www spelling and the bare domain are different hosts. They can have different DNS records, different certificates, different redirect rules and different answers on port eighty. An audit that probed one has said nothing whatever about the other — and an honest one says so rather than implying it covered both.

Reachable, or answering, or refusing

The third case is about the detail rather than the host, and it is the most instructive.

On a large retail site the plain-http address returned 404 — to the crawler and to a browser alike. The report said the insecure version was still reachable and that there were two indexable copies of every page. Neither is true of a 404. Nothing is reachable and nothing is indexable. The real harm is smaller and completely different: somebody who types the bare domain gets an error page instead of the site.

The title was right and the detail was wrong, and that combination is more dangerous than being wrong outright — because a reader who checks the detail finds it false and stops trusting the findings that are true.

So "http is still reachable" is really three situations:

• It answers 200 and serves the site. This is the real problem: an insecure copy of every page, indexable, splitting signals with the secure one.
• It answers an error. Nothing is duplicated and nothing is indexed. The cost is visitors who type the domain without a scheme and land on an error.
• It refuses, times out, or errors on the server side. The tool has learned nothing. A server failing on its plain-http listener has not told you whether a working listener would redirect, and a finding that draws a conclusion here is inventing one.

Reading a security finding on your own report

• Find the host before you check the claim. If the report does not name one, that is the first thing to be sceptical about — not the claim itself.
• Check where your audit started and where it landed. If the crawl followed a redirect, everything after that is about the destination.
• Test both spellings by hand — the bare domain and the www one, each over plain http. They are separate configurations and it takes a minute.
• Read the status, not the summary. A 200 and a 404 on the same address call for different work and appear under the same heading in most tools.

When this matters, and when it does not

Keep the severity in view. An insecure copy serving 200 is a genuine and common problem, and worth fixing the day you find it. An http address that errors is a courtesy fix — real, small, and not urgent. And a certificate close to expiry on any host your traffic touches is urgent wherever it lives, which is exactly why naming the host matters more than the number of days.

The fixes that make it worse

• Adding a redirect rule for the spelling that already worked. The finding was about the other one, and now you have two rules to maintain and one of them does nothing.
• Dismissing a finding you disproved on the wrong host. The most expensive response on this page, and the one every unnamed finding invites.
• Renewing the certificate you checked. It was not the one expiring.

How to make this finding disappear without fixing anything

Turn off the plain-http listener entirely. Nothing answers, so nothing can be reported — and anybody who types your domain without a scheme now gets a connection error rather than your site. The finding is quieter and the visitor is worse off, which is a fair summary of what happens when you optimise for a report instead of for a person.

Where this sits in an audit

The registered check is security.https, which covers the plain-http address and the certificate. For the repair itself — the redirect, where to configure it by host, and why HSTS is a separate step — see how to redirect http to https →. For the broader question of which spelling of your domain is canonical, see www versus non-www, counted rather than asserted →.

Common questions

My audit says my certificate expires soon but it does not. Why?

Probably because the crawl followed a redirect and the certificate belongs to the destination host. Check the address your pages actually resolve to rather than the one you typed.

Are www and the bare domain the same host?

No. They can have different DNS records, certificates, redirect rules and answers over plain http, so a probe of one says nothing about the other.

Is http returning 404 the same as an insecure copy of my site?

No, and the difference matters. A 404 means nothing is reachable and nothing is indexable; the only cost is that somebody typing your domain without a scheme sees an error page.

What should a finding say when the http address refuses or times out?

That it could not tell. A server failing on its plain-http listener has not revealed whether a working listener would redirect, so any conclusion drawn there is invented.

Should I just turn off plain http?

It silences the finding and leaves visitors who type your domain without a scheme with a connection error. Redirect instead — that is what the address is for.