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.
Associated attack or threat scenario
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
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
- Provision a valid certificate for the exact target hostname.
- Enable HTTPS on the public edge and ensure every route and status code is served correctly.
- Remove mixed-content dependencies and mark sensitive cookies `Secure` and `HttpOnly` as appropriate.
- 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.
server { listen 80; server_name example.com; return 308 https://$host$request_uri; }
server { listen 443 ssl http2; server_name example.com; }
<VirtualHost *:80>
ServerName example.com
Redirect permanent / https://example.com/
</VirtualHost>
Set SSL/TLS encryption mode to Full (strict), enable Always Use HTTPS, and keep the origin certificate valid.
Verify the fix
- Run `curl -I https://example.com/` and confirm a valid response.
- Verify the certificate and SNI path with OpenSSL.
- Test representative application routes, error pages, and static assets.
- Use browser developer tools to confirm there is no active mixed content.
After DNS, CDN, certificate, mail, or application propagation completes, run a fresh SecuTest scan and compare the new evidence with the original finding.
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.