TLS and web security check

No HTTPS: website served without encryption

Without HTTPS every request and response, including form submissions, session cookies and credentials, travels in cleartext across every network between the visitor and the server.

How to fix it: Issue a certificate, Let's Encrypt is free and automatable, and serve the site over 443. Once HTTPS works, redirect all HTTP traffic to it permanently and add an HSTS header so browsers stop attempting the insecure scheme.

TLS certificate on malware blacklist

SSLBL lists certificates observed terminating botnet command-and-control or malware-distribution traffic. A fingerprint match is exact: it is the same certificate, not a similar one.

How to fix it: Treat the host as potentially compromised. Revoke and reissue the certificate with a fresh key pair, audit the server for unauthorised services, then request delisting from abuse.ch once the malicious activity has stopped.

HTTPS not available

Without HTTPS every request and response, including form submissions, session cookies and credentials, travels in cleartext across every network between the visitor and the server.

How to fix it: Issue a certificate, Let's Encrypt is free and automatable, and serve the site over 443. Once HTTPS works, redirect all HTTP traffic to it permanently and add an HSTS header so browsers stop attempting the insecure scheme.

SSL certificate expired

The certificate presented by this site has passed its expiry date. Certificates expire deliberately, to bound the damage from a key compromise nobody noticed.

How to fix it: Renew now. If this is a host you had forgotten, that is the more important finding: decide whether it should still be running at all. Automate renewal (certbot, or your platform's managed certificates) and alert on certificates within 30 days of expiry, because manual renewal reliably fails eventually.

SSL certificate expiring soon

Expired certificates cause browser warnings and break secure connections

How to fix it: Renew at least 14 days before expiry. If you are not already on auto-renewal, switch now: certbot, AWS Certificate Manager, and Cloudflare Universal SSL all handle renewal without operator action. Add a calendar alert or monitoring check for any certificate that cannot be auto-renewed.

TLS handshake failed

Something is listening on the HTTPS port, but the TLS negotiation does not complete. This is a broken configuration rather than an absent one.

How to fix it: Test with openssl s_client -connect host:443 -servername host. The usual causes are an incomplete certificate chain (missing intermediates), a protocol floor above what clients offer, or SNI misconfiguration on a shared address.

Self-Signed certificate

The certificate is self-signed or issued by an authority no browser trusts. Nothing independent vouches for the identity of this server, which is the entire purpose of a certificate.

How to fix it: Replace it with a certificate from a publicly trusted CA: Let's Encrypt is free and automatable. If this host is genuinely internal-only, it should not be reachable from the public internet; restrict it at the firewall rather than leaving a warning-generating service exposed.

Weak cipher suites detected

Weak ciphers are vulnerable to cryptographic attacks

How to fix it: Restrict your server to TLS 1.2 and 1.3 with modern AEAD cipher suites (e.g. ECDHE-ECDSA-AES128-GCM-SHA256, TLS_AES_128_GCM_SHA256). Use the Mozilla SSL Configuration Generator on the intermediate profile, and disable RC4, 3DES, and MD5-based suites entirely.

Weak TLS version

TLS 1.0 and 1.1 have known cryptographic weaknesses and were deprecated by the IETF in 2021. Their continued presence usually means the configuration has not been reviewed in years.

How to fix it: Set a minimum of TLS 1.2 and enable 1.3: ssl_protocols TLSv1.2 TLSv1.3; on nginx. Check your traffic first if you serve very old clients, but in practice anything that cannot do 1.2 also cannot be secured. Verify afterwards with SSL Labs or testssl.sh.

Insecure cookie configuration

Secure and HttpOnly flags protect sensitive cookies

How to fix it: Set Secure, HttpOnly, and SameSite=Lax (or Strict for high-security flows) on every session and authentication cookie. In Express: app.use(session({ cookie: { secure: true, httpOnly: true, sameSite: 'lax' }})). Most modern frameworks default these; legacy applications usually need an explicit configuration line.

Cookies missing httponly flag

HttpOnly makes a cookie invisible to JavaScript. Session cookies without it can be read by any script running on the page, including one injected through an XSS flaw or loaded from a compromised third-party dependency.

How to fix it: Set HttpOnly on every cookie that JavaScript does not genuinely need to read: session identifiers above all. Combine with Secure and SameSite=Lax (or Strict). If a script currently reads the session cookie, move that data to a separate non-sensitive cookie rather than weakening the session one.

HTTP not redirecting to HTTPS

HTTPS is available on this site, but plain HTTP requests are still served rather than redirected. Visitors who type the domain, follow an old link, or use a bookmark stay on the unencrypted version.

How to fix it: Issue a permanent redirect from HTTP to HTTPS for every path: return 301 https://$host$request_uri; on nginx, or Redirect permanent on Apache. Once that is reliable, add HSTS so browsers stop making the insecure request in the first place.

HSTS header missing

HSTS tells a browser to only ever reach this site over HTTPS, and to refuse to let the user click through a certificate warning. Without it, the very first request a visitor makes, typing the domain, or following an http:// link, happens in cleartext before any redirect can protect it.

How to fix it: Add Strict-Transport-Security: max-age=31536000; includeSubDomains once every subdomain reliably serves HTTPS. Start with a short max-age (a few hours) to confirm nothing breaks, then raise it: the header is hard to undo, because browsers honour the cached value. Consider preload and submission to hstspreload.org only after the long max-age has run without incident.

X-XSS-Protection header missing

This header enables browser XSS protection

How to fix it: Modern browsers have deprecated X-XSS-Protection in favor of Content-Security-Policy. Set X-XSS-Protection: 0 and invest in a strong CSP (default-src 'self', no unsafe-inline, no unsafe-eval). CSP is the load-bearing mitigation; the legacy header is informational.

Apex does not serve HTTPS directly

The hostname does not answer on HTTPS itself, but sends visitors to one that does. Traffic is protected after the redirect; the initial request is not.

How to fix it: Serve a certificate on the apex as well and redirect at the HTTPS layer rather than from plain HTTP. Most CDNs and load balancers will issue an apex certificate automatically.

Security headers missing

CSP tells the browser which sources of script, style and content are legitimate for your site. It is the single most effective defence against cross-site scripting, because it stops injected script from executing even when the injection itself succeeds.

How to fix it: Start in report-only mode: Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report. Collect violations for a week to find what legitimately loads from elsewhere, tighten from there, then switch to the enforcing header. Do not begin with a permissive policy containing unsafe-inline: that defeats the point.

No web service detected

Neither port answered. Many domains exist only for email or DNS and are never meant to serve a website.

How to fix it: Confirm whether this hostname is supposed to serve web content. If it is not, no action is needed: consider a null MX and an explicit DNS record set to make the intent clear. If it is, check that the service is running and not firewalled.