The site does not answer over HTTPS

CriticalConfirmedhttp.reachability.https-unreachable

What this check looks for

Nothing responded on the secure port. Either the site is down, the encrypted service is not running, or something between us and it is blocking the connection.

Why it matters

Every browser goes to HTTPS first now. A site that does not answer there is unreachable for most visitors regardless of what plain HTTP does, and the rest of the security report cannot be produced at all.

When the check passes, your report says: “The site answers over HTTPS”.

What it costs your score

When this check fails it removes 60 points from your HTTP score, before the status, confidence and repeat multipliers are applied. HTTP carries a weight of 7 in the overall score.

It shares the http.reachability family ceiling of 60 points: however many findings that family produces, together they cannot remove more than that from HTTP. One underlying problem showing up in several places is still one problem.

Severity: critical
Default confidence: confirmed
Status when triggered: fail
Deduction: 60 points
Family cap: http.reachability · 60
Category: HTTP
Module: Http reachability
Fix owned by: user
In the ruleset since: 2026.09

How the whole score is calculated

How to fix it

Get the site answering on port 443.

Nothing else in the web half of this report can be checked until it does.

Confirm something is listening: ss -lntp | grep :443 on the host.
Confirm the firewall allows 443 inbound from outside, not only from your network.
Confirm DNS points at the host actually serving the site.
Try the handshake directly: openssl s_client -connect ‹host›:443.

How to confirm it worked

curl -sSI https://‹host›/ — expect a status line

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

nginx

server {
	listen 443 ssl;
	listen [::]:443 ssl;
	http2 on;
	server_name ‹host›;

	ssl_certificate     /etc/letsencrypt/live/‹host›/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/live/‹host›/privkey.pem;
}

Apache

<VirtualHost *:443>
	ServerName ‹host›
	SSLEngine on
	SSLCertificateFile    /etc/letsencrypt/live/‹host›/fullchain.pem
	SSLCertificateKeyFile /etc/letsencrypt/live/‹host›/privkey.pem
</VirtualHost>

Caddy

‹host› {
	root * /srv/www
	file_server
}

This is a server-context block; it cannot be set from .htaccess.
Caddy listens on 443 and obtains a certificate with no further configuration.

Technical detail

A request to https://‹host›/ failed: ‹error›.

The usual causes, in the order worth checking: the TLS service is not listening on 443; a firewall or security group drops the port; the DNS record points somewhere that no longer serves the site; or the TLS handshake itself fails, which shows up here as a connection error rather than as a certificate finding.

Standards and references

RFC 9110 — HTTP Semantics

Test this on your domain

Run the check that produces this finding, on its own, against any domain.

Open the http reachability checker