http.https_available Reviewed July 2026

Quick fix

Provision a valid certificate for the exact target hostname.

What this finding means

SecuTest sends a bounded HTTPS HEAD request to the submitted target host. The finding covers the externally observed web endpoint and may differ from the registrable domain's root service.

Interpretation boundary Use the exact evidence in your report. SecuTest reports externally observable conditions; it does not assume ownership, exploitability, compromise, or business intent when those cannot be proven remotely.

Associated attack or threat scenario

Threat type Traffic interception, content tampering, session theft, and credential capture

How the attack or failure scenario works

On plaintext HTTP, an on-path attacker can observe requests, inject scripts or redirects, alter downloads, and capture credentials or session tokens sent without secure protection. HTTPS prevents passive reading and detects active modification when certificate validation succeeds.

Conditions and limitations

  • The site is reachable over plaintext HTTP or users can be directed to an insecure endpoint.
  • The attacker controls or observes a network path such as public Wi-Fi, a router, proxy, or ISP segment.
  • The application transmits sensitive data or trusted content over that path.

Why it matters

Security and business impact Without a retrievable HTTPS response, web traffic cannot rely on transport confidentiality, integrity, and authenticated server identity.

Step-by-step fix

Where to make the change

  • The outermost component emitting the public HTTP response: CDN, reverse proxy, ingress, web server, or application middleware.
  • Apply the control consistently to normal pages, redirects, error responses, and relevant subdomains.

Remediation procedure

  1. Provision a valid certificate for the exact target hostname.
  2. Enable HTTPS on the public edge and ensure every route and status code is served correctly.
  3. Remove mixed-content dependencies and mark sensitive cookies `Secure` and `HttpOnly` as appropriate.
  4. Redirect HTTP to HTTPS and add HSTS only after HTTPS is stable.

Commands and configuration examples

Replace example values with the hostname, selector, IP address, port, provider, or policy values shown in your SecuTest evidence. Review every example before production use.

Nginx redirect and TLS
server { listen 80; server_name example.com; return 308 https://$host$request_uri; }
server { listen 443 ssl http2; server_name example.com; }

Apache redirect
<VirtualHost *:80>
    ServerName example.com
    Redirect permanent / https://example.com/
</VirtualHost>

Cloudflare
Set SSL/TLS encryption mode to Full (strict), enable Always Use HTTPS, and keep the origin certificate valid.

Verify the fix

  1. Run `curl -I https://example.com/` and confirm a valid response.
  2. Verify the certificate and SNI path with OpenSSL.
  3. Test representative application routes, error pages, and static assets.
  4. Use browser developer tools to confirm there is no active mixed content.
Confirm the externally visible result

After DNS, CDN, certificate, mail, or application propagation completes, run a fresh SecuTest scan and compare the new evidence with the original finding.

Re-scan your domain

Common mistakes

  • Using Cloudflare Flexible mode, which leaves the edge-to-origin connection unencrypted.
  • Securing only the home page while API or asset hostnames remain HTTP.
  • Adding HSTS before all required subdomains support HTTPS.

Authoritative references