Skip to main content

How to use SSL, header and security tools to check a site safely

What our free SSL, security-header, HSTS, DNSSEC and open-redirect tools check, and how to interpret and act on each result.

Before you harden a server, it helps to see what it looks like from the outside. Our free security tools report the same signals a browser or an attacker sees first. Here is what each one checks and what to do about the result.

SSL/TLS certificate check

The SSL certificate checker and SSL expiry monitor show who issued the certificate, which names it covers (the SANs), the expiry date, and whether the chain is complete.

  • Name mismatch → the certificate does not cover the hostname you requested (e.g. it is for example.com but you asked for www.example.com). Fix by issuing a cert that includes both names.

  • Expired / expiring → renew. An expired certificate triggers a full-page browser warning and kills trust and rankings instantly.

  • Incomplete chain → some clients will reject it; install the intermediate certificate.

  • Weak protocol/cipher → disable TLS 1.0/1.1 and legacy ciphers.

Certificates are free (Let's Encrypt and others) — see Free TLS certificates.

Security headers check

The security headers checker reports the response headers that instruct browsers how to protect your visitors:

HeaderProtects against
Strict-Transport-Security (HSTS)SSL-stripping downgrade attacks
Content-Security-Policy (CSP)Cross-site scripting (XSS)
X-Content-Type-Options: nosniffMIME-type confusion attacks
X-Frame-Options / frame-ancestorsClickjacking
Referrer-PolicyLeaking URLs to third parties

Missing headers are not always critical, but adding them is cheap and moves you toward a passing grade on external scanners. Start with HSTS once HTTPS is solid, then a Content-Security-Policy.

HSTS preload check

The HSTS preload checker verifies the HSTS header's max-age, includeSubDomains and preload directives. Caution: preloading is hard to reverse — only enable preload for a domain whose entire subdomain tree is HTTPS-ready.

DNSSEC check

The DNSSEC checker confirms your zone is cryptographically signed and the chain of trust is valid. DNSSEC prevents DNS spoofing (a forged answer redirecting your visitors). It needs correct DS records at the registrar; a broken delegation is worse than none, so enable it deliberately.

Open redirect check

The open redirect checker finds whether your URLs let an attacker bounce users to an arbitrary site through a redirect (a phishing aid). The fix is to whitelist redirect targets rather than reflecting user input.

Redirect & header inspection

The redirect chain visualiser, HTTP header checker and www-redirect checker round out the picture — they show whether HTTP→HTTPS, www→apex and trailing-slash redirects are configured cleanly, with no loops and no mixed content.

In what order to fix things

  1. Valid, renewing TLS covering all your names.

  2. Force HTTPS with a clean redirect and HSTS.

  3. Basic security headers (nosniff, frame-ancestors, referrer-policy).

  4. CSP — start permissive, tighten over time, watch the console.

  5. DNSSEC — once DNS is stable and you control the registrar.

Our Security checklist is the full go-live list, and if you would rather have it handled, Server Management covers hardening as a service.