// HUB / WEBSITES
Website Security Tools
Check any site's TLS certificate and HTTP security headers — what is configured, what is missing, and what each setting actually protects against.
// Tools in this section
// What a browser checks before it trusts a page
Two things decide how safe a page is before any of its content loads: whether the connection is genuinely encrypted and genuinely with the site it claims to be, and what instructions the server gives the browser about how to treat what it sends. The tools here inspect both, for any public site.
The certificate is the identity half. When you connect over HTTPS the server presents a certificate signed by an authority your browser already trusts, proving it controls that domain. The SSL Certificate Checker completes a real TLS handshake and reports what came back: who issued the certificate, which hostnames it covers, when it expires, which TLS version and cipher were negotiated, and whether the chain validates. Expiry is far and away the most common failure — certificates now typically last 90 days, and one that is not renewed turns a working site into a full-page browser warning overnight.
Headers are the instruction half. Alongside the page, a server sends response headers telling the browser how to behave: whether to insist on HTTPS from now on (Strict-Transport-Security), which scripts may run (Content-Security-Policy), whether other sites may frame the page (X-Frame-Options), whether to second-guess declared content types (X-Content-Type-Options), and how much of the URL to leak when someone clicks away (Referrer-Policy). Each is a line of configuration, and each closes off a category of attack.
The Security Headers Check fetches a URL, grades what it finds and explains what each header would have prevented. Treat the grade as a prompt rather than a verdict: a site can score well and still be insecure in ways headers cannot see, and a poor score is not evidence of compromise. What it tells you reliably is which cheap, high-value defences are not switched on yet.
Both tools only read what any visitor's browser already receives. Neither probes, scans ports nor tests for vulnerabilities, so running them against sites you do not own is no different from visiting those sites.
// Frequently asked questions
- What does an SSL certificate actually prove?
- That whoever holds it demonstrated control of the domain to a certificate authority, and that the connection is encrypted. It says nothing about the honesty of the site — phishing sites obtain valid certificates too, so a padlock means 'private connection', not 'trustworthy business'.
- My certificate is valid but browsers still warn. Why?
- Usually the hostname does not match any name on the certificate, an intermediate certificate is missing from the chain the server sends, or a clock is wrong. The checker reports hostname match, chain and trust separately so you can tell which one applies.
- How long before expiry should I renew a certificate?
- Automate it. Most certificates now last 90 days and ACME clients renew at roughly a third of remaining life. If you renew by hand, treat 30 days as the point to act — and monitor, because nobody notices an expiry until users do.
- Do security headers slow a site down?
- No — they are a few hundred bytes of response headers. The real cost is testing: a strict Content-Security-Policy can break inline scripts and third-party widgets, which is why it is normally rolled out in report-only mode first.
- Is a poor header grade a vulnerability?
- Not in itself. It means known, inexpensive defences are missing, which widens the blast radius when something else goes wrong. A missing CSP does not create a cross-site scripting bug, but it removes the layer that would have contained one.