HTTPS Consistency

Every public-facing host should serve HTTPS. Plain HTTP exposes credentials, session cookies, and content to anyone on the network path; injection attacks against unencrypted pages can hijack sessions or rewrite responses. RedScore checks the scheme of each probed host and verdicts on coverage. Free TLS is universally available through Let's Encrypt and is built into every major CDN and managed platform; there is no longer a cost or complexity reason to leave a host on HTTP.

How the check works

RedScore reads the same web probe artifact used by other Web and Infrastructure checks. For each successful probe, it records whether the host responded over HTTPS or HTTP. Coverage is the ratio of HTTPS hosts to total reachable hosts. This check looks only at the scheme, not certificate validity. An expired or untrusted cert that still serves HTTPS content passes here; cert hygiene lives in the Certificate Transparency category.

How the verdict maps to evidence

• Pass (10/10): every reachable host served HTTPS.
• Warn (5/10): mixed scheme. Some hosts on HTTPS, others on HTTP only. The scheme_rows array shows each host's scheme and status code.
• Fail (0/10): no host served HTTPS.

Fail or warn: enable HTTPS on every host

Walk the scheme_rows array. Anything with scheme: "http" needs HTTPS. The path depends on how the host is hosted.

Managed platforms (zero-config TLS)

If your host runs on Vercel, Netlify, Cloudflare Pages, Render, Fly.io, Heroku, App Engine, or similar, TLS is included automatically. Check that the custom domain is attached and the platform's auto-TLS has finished issuance. In each platform's dashboard:

• Add the hostname as a custom domain in the project settings.
• Update DNS to point at the platform's CNAME or apex target.
• Wait a few minutes for the platform to issue and deploy a cert.

CDN front door (also zero-config)

If you put your origin behind Cloudflare, CloudFront, Fastly, or similar, the CDN terminates TLS for free.

• Cloudflare: enable the orange-cloud proxy on the record. Cloudflare provisions a Universal SSL cert automatically.
• AWS CloudFront: create a distribution, request a free public cert through ACM (us-east-1 region), attach to the distribution.
• Fastly, Akamai: TLS is included; configure the service to use it for the hostname.

Self-hosted

If you operate the web server directly, use an automated ACME client to issue and renew Let's Encrypt certs:

• Caddy: TLS is on by default. Add the domain to the Caddyfile and Caddy issues and renews automatically.
• Traefik: configure the cert resolver, add the host to a router, automatic from there.
• nginx + certbot: certbot --nginx -d yourdomain.tld walks through issuance and updates nginx config in one command. Renewal runs via cron or systemd timer (certbot installs both).
• Apache + certbot: certbot --apache -d yourdomain.tld is the equivalent.
• acme.sh: portable shell-based ACME client, useful when certbot is not available.

Always redirect HTTP to HTTPS

Once HTTPS is live, redirect HTTP traffic to HTTPS. This catches users who type yourdomain.tld without a scheme, plus old links and bookmarks.

server {
    listen 80;
    server_name yourdomain.tld;
    return 301 https://$host$request_uri;
}

<VirtualHost *:80>
    ServerName yourdomain.tld
    RewriteEngine On
    RewriteRule ^/?(.*) https://%{HTTP_HOST}/$1 [R=301,L]
</VirtualHost>

Once redirects are in place and verified, publish a Strict-Transport-Security (HSTS) header so browsers refuse to use HTTP for your domain at all (see the Strict-Transport-Security check in Web Application Security).

Verify the fix

• For each host: curl -I http://yourhost should return a 301 or 302 redirect to https://yourhost.
• curl -I https://yourhost should return a 200 (or whatever the page normally returns) without cert warnings.
• Test from a few different networks if you have firewall rules that vary per region.
• Re-run the RedScore lookup. The verdict moves to pass when every reachable host responds over HTTPS.

Common pitfalls

• Auto-issued cert for the wrong hostname. Each platform issues for the hostname you configure; if your DNS points the right hostname at the platform but the platform has issued for a different name, browsers will warn. Verify the cert SAN list with openssl s_client -connect host:443 -servername host < /dev/null | openssl x509 -text | grep DNS:.
• DNS not yet pointed at the new TLS endpoint. Auto-TLS only works once the platform sees DNS pointing at it. Check propagation if issuance is failing.
• Mixed content on the page. The probe checks the scheme of the page itself, not the assets it loads. A page served over HTTPS that pulls scripts over HTTP triggers browser blocking and degrades trust. Audit with browser devtools.
• Forgotten internal hostnames exposed publicly. Internal-only hosts that ended up in public DNS sometimes serve HTTP because they were never expected to face the internet. Either lock them down with firewall rules so they are not reachable, or enable TLS.
• Cert chain incomplete. Some servers serve only the leaf cert without the intermediate. Most browsers handle this via AIA fetching, but older mobile clients, IoT devices, and server-to-server callers refuse to validate. Configure the server to send the full chain.