What does the SSL checker actually test?

It opens a real TLS connection to the host you enter and reports five things: whether the certificate is installed, valid and trusted; whether the intermediate chain is complete; the expiry date and days remaining; the Subject Alternative Names the certificate covers; and the protocol versions and cipher suites the server negotiates, including any known-weak ones.

Why does my certificate show as not trusted when it works in my own browser?

Almost always a missing intermediate certificate. Your browser may already have the intermediate cached from another site, so it fills the gap silently, but a fresh client does not. The fix is to install the full chain (leaf + intermediates) on the server. The checker flags this because it validates the chain as a clean client would.

Does a valid certificate mean my server is secure?

No. A certificate proves identity and enables encryption, but the server can still negotiate obsolete protocols (TLS 1.0/1.1), weak ciphers, or be exposed to vulnerabilities like POODLE or ROBOT. Certificate validity and configuration security are two separate checks; this tool reports both.

How often should I check my SSL certificate?

Check after every certificate renewal or server change, and set an expiry reminder. With short-lived certificates (90 days or less) now standard, automated monitoring is more reliable than manual checks.

Can I check certificates on internal or private hostnames?

No. The tool connects from the public internet, so it can only test publicly reachable hostnames. For internal names, run the equivalent check locally with OpenSSL: openssl s_client -connect host:443 -servername host.

Security Headers Test

Check which HTTP security response headers a site sends. This tool reports the actual header values, the server hostname, the HTTP status code and the full set of raw response headers — with no letter grade, just the data.

About this test

This tool requests a site's HTTP response headers — following redirects when the option above is ticked, and over HTTP/2 where the server supports it — and reports, with no letter grade, exactly what it found: which of the 15 tracked security headers are present or missing (each with its severity, a Recommended/Optional tag and the header's actual value), the server hostname (reverse-DNS of the responding IP), the IP address, the negotiated HTTP version, the status code, content type and encoding, the parsed HSTS policy, any information-disclosure headers, cookie flags, and the full raw response. The aim is to surface the facts so you can decide what to change — not to collapse your site into one score.

How to read the results

Recommended vs Optional

Recommended headers should be set on virtually any public website. They are the OWASP Secure Headers Project “core” set plus the headers graded by securityheaders.com: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and X-Permitted-Cross-Domain-Policies.

Optional headers are situational or advanced. The cross-origin isolation set (Cross-Origin-Opener/Embedder/Resource-Policy) mainly matters when you need SharedArrayBuffer or strong process isolation; Clear-Site-Data belongs on logout endpoints rather than site-wide; Upgrade-Insecure-Requests is a migration aid that HSTS makes redundant; and X-XSS-Protection is deprecated — current guidance from OWASP and MDN is to send X-XSS-Protection: 0 and rely on a strong Content-Security-Policy instead. “Optional” does not mean unimportant; it means apply it where it fits your application.

Severity scale

Severity reflects the impact if a header is absent, drawing on the OWASP Secure Headers Project, the OWASP Top 10 risk weighting, and NIST control families — e.g. SC-8 (transmission confidentiality & integrity) and SC-23 (session authenticity) in NIST SP 800-53 Rev. 5.

Severity	What it means	Headers
Critical	Its absence leaves the site directly exposed to a high-impact attack class with no built-in fallback.	Content-Security-Policy — primary defence against cross-site scripting / injection (OWASP Top 10 A03).
High	Protects the transport channel or isolates the browsing context; absence enables downgrade/MITM or cross-origin leakage.	Strict-Transport-Security (NIST SP 800-52r2 / RFC 6797), Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy.
Medium	Blocks a specific, common attack class.	X-Frame-Options (clickjacking), X-Content-Type-Options (MIME-sniffing), Cross-Origin-Resource-Policy.
Low	Defence-in-depth and privacy hardening — reduces attack surface but is not a primary control.	Referrer-Policy, Permissions-Policy, X-Permitted-Cross-Domain-Policies, X-DNS-Prefetch-Control, Origin-Agent-Cluster, Clear-Site-Data, Upgrade-Insecure-Requests.
Informational	Legacy or deprecated — reported for awareness, not a current control.	X-XSS-Protection (deprecated; send `0` and use CSP).

Compliance readiness

HTTP security headers are recognised technical controls that help satisfy and provide audit evidence toward the web-application and data-in-transit requirements of the major frameworks. They are one layer of a wider control set — a header's presence is supporting evidence, not certification of compliance in itself.

Framework	Relevant control / clause	How these headers help
PCI DSS v4.0	Req. 6.4.3 & 11.6.1 (payment-page script management + HTTP-header tamper detection — mandatory since Mar 2025); Req. 4 (encrypt transmission of cardholder data)	Content-Security-Policy authorises and scopes the scripts a payment page may load (6.4.3); the response-header set is exactly what 11.6.1 requires you to monitor for unauthorised change; HSTS enforces TLS for cardholder data in transit (Req. 4).
SOC 2 Type II	AICPA Trust Services Criteria — Security (CC6.1, CC6.6, CC6.7)	HSTS, CSP, X-Frame-Options and related headers are demonstrable web-hardening controls that evidence protection of data in transit and against unauthorised access — operating consistently across the audit period.
ISO/IEC 27001:2022	Annex A 8.24 (use of cryptography) and 8.26 (application security requirements)	HSTS evidences enforced encryption in transit (8.24); the overall header posture is part of the application-security controls expected by 8.26.
GDPR	Art. 32 (security of processing) and Art. 25 (data protection by design & by default)	HSTS encrypts personal data in transit; CSP mitigates XSS that could exfiltrate it; Referrer-Policy prevents personal data leaking to third parties through the `Referer` header.
HIPAA	Security Rule — Transmission Security §164.312(e) and Integrity §164.312(c)	HSTS guards electronic PHI in transit; CSP and anti-clickjacking controls reduce web-application risk to PHI integrity.
NIST	SP 800-52r2 (recommends HSTS); SP 800-53r5 SC-8 / SC-23 / SI-10; Cybersecurity Framework 2.0 PR.DS	Direct mapping to transmission confidentiality & integrity, session authenticity, input handling and data-in-transit protection.
PSD2 (SCA-RTS)	Commission Delegated Reg. (EU) 2018/389, Art. 35 — common & secure communication	HSTS enforces the “strong and widely recognised encryption throughout the communication session” the RTS requires; CSP protects the integrity of the payment session.

Standards & references

OWASP Secure Headers Project — the recommended header set and values.
OWASP HTTP Headers Cheat Sheet and Clickjacking Defense Cheat Sheet.
NIST SP 800-52 Rev. 2 — TLS configuration guidance; recommends HSTS.
NIST SP 800-53 Rev. 5 — controls SC-8 (transmission confidentiality & integrity) and SC-23 (session authenticity).
MDN Web Docs — HTTP headers — per-header behaviour and browser support.
RFC 6797 (HSTS) and W3C Content Security Policy Level 3.
Compliance: PCI DSS v4.0 (Req. 6.4.3 / 11.6.1) · AICPA SOC 2 · ISO/IEC 27001:2022 (A.8.24 / 8.26) · GDPR Art. 32 · HIPAA Security Rule (§164.312) · NIST CSF 2.0 · PSD2 SCA-RTS (EU) 2018/389.