The fix, in one snippet
sudo certbot --nginx -d example.com -d www.example.comIllustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
Scan.now opens a TCP connection to port 443 of the hostname you entered and attempts a TLS handshake with a modern client configuration: TLS 1.2 and 1.3 offered, Server Name Indication set to the hostname, and a current public root store. If the handshake completes, it sends GET / over HTTPS and records the status code. The check fails when the connection is refused or times out, when the server answers with a TLS alert (no shared protocol or cipher suite), or when the HTTPS listener responds with a connection close or a 5xx on every attempt. Certificate problems are reported separately under certificate-valid; this check only asks whether an encrypted channel can be established at all. It is rated critical because HSTS, secure cookies, HTTP/2 and most modern browser APIs all depend on it.
Why it matters
Without HTTPS, anyone positioned between the visitor and your server can read and rewrite every request and response: the operator of a coffee-shop Wi-Fi network, a compromised home router, an ISP injecting adverts, or a government-scale interception point. A realistic scenario is an attacker on a shared network who injects a single <script> tag into your homepage and captures every username and password typed into it. Session cookies travel in the clear and can be replayed. Browsers now label plain-HTTP pages "Not secure", Chrome and Firefox offer HTTPS-first modes that warn before loading them, and secure-context-only features such as geolocation, service workers and the Web Crypto API are unavailable. Search engines have treated HTTPS as a ranking signal since 2014.
How to fix it
Obtain a certificate from a publicly trusted CA and configure your server to listen on 443. Let's Encrypt issues free certificates through the ACME protocol and Certbot automates both issuance and renewal:
sudo certbot --nginx -d example.com -d www.example.com
# or, for Apache:
sudo certbot --apache -d example.com -d www.example.comA minimal nginx server block once the certificate exists:
server {
listen 443 ssl;
http2 on;
server_name example.com www.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
}Apache equivalent:
<VirtualHost *:443>
ServerName example.com
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
SSLProtocol -all +TLSv1.2 +TLSv1.3
</VirtualHost>If the domain is proxied through Cloudflare, Universal SSL provides the edge certificate automatically; set SSL/TLS encryption mode to Full (strict) so the hop to your origin is also verified. Once HTTPS works, add the redirect from HTTP and an HSTS header. Our SSL and TLS guide explains the handshake and certificate model in more depth, and the SSL checker re-tests a single host quickly.
Where this fits
HTTPS is available is check 2 of 12 that the website vulnerability scanner runs under transport security (https / tls), ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits Certificate chain and hostname validation (critical), where the certificate presented for this hostname did not validate: The chain does not reach a trusted root, an intermediate is missing, the name does not match, or the certificate is self-signed or expired. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
HTTPS is available closes one route in. Immediately below it: Certificate expiry, where the certificate has expired or will expire within 30 days; Deprecated TLS versions accepted (1.0 / 1.1), where the server still completes handshakes with TLS 1.0 or TLS 1.1; HTTP redirects to HTTPS, where port 80 serves page content instead of redirecting to HTTPS, or the redirect chain is wrong.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Exposed .env configuration file, where a .env configuration file is served from the web root, and Exposed .git repository, where the site's .git directory is reachable over HTTP. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: HTTPS is available (critical severity)
Scanner check id: https-availableThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.
