The SSL Certificate Checker opens a real TLS handshake to any public hostname and reports on the full HTTPS surface: expiry (colour-coded for the 30-day and 7-day danger zones), issuer, subject alt names, self-signed status, hostname match, TLS version (TLS 1.3 / 1.2 / deprecated 1.0/1.1), cipher suite and bit strength, public-key algorithm (RSA size or ECDSA curve), embedded Signed Certificate Timestamps (CT compliance), the full certificate chain (leaf → intermediates → root), and the SHA-256 fingerprint. It also fetches the page over HTTPS to scan for mixed content — every http:// script, stylesheet, iframe, image, video, audio, or object embedded on your HTTPS page — split into active (browsers block) and passive (browsers warn). Reads the Strict-Transport-Security header (max-age, includeSubDomains, preload, and hstspreload.org eligibility) and verifies that http:// redirects to https:// in a single 301 hop. Applies a scoring rubric (A+ through F) that weights expiry, trust, hostname match, TLS version, HSTS, and mixed content. Ideal for pre-launch checks, quarterly renewal audits, and diagnosing the "padlock is not secure" warnings customers report.
What a TLS certificate actually proves
A TLS certificate proves two things: 1. that the server owns the hostname it claims to serve (verified by the certificate authority when it issued the cert), and 2. that the connection is encrypted against passive eavesdroppers on the network path. What it does not prove: (a) that the site is safe or trustworthy (a phishing site can have a perfectly valid cert — cheap DV certs verify domain control, not business identity), (b) that the site isn't compromised (a hacked server can serve malware over TLS just fine), or (c) that the specific page content wasn't modified (that's what signed content or subresource integrity is for). For SEO, a valid TLS certificate is table stakes — Google has treated HTTPS as a ranking signal since 2014 and modern browsers explicitly mark non-HTTPS sites as "Not Secure." A broken or expired cert doesn't just lose ranking — customers can't even reach the page.
The three types of TLS certificates (and why DV is fine)
DV (Domain Validation). Issuer confirms you control the domain (via a DNS record or an HTTP challenge). Issued in minutes. Free from Let's Encrypt and other ACME CAs. This is what 95%+ of the web uses and it's completely fine — it does the encryption job and includes the domain in the SAN list. OV (Organization Validation). Issuer confirms your organization exists in a corporate registry. Takes a day or two. Shows organization name in cert details but not in the browser bar. Modest business signal. EV (Extended Validation). Full legal identity verification, several days, more expensive. Used to show a green "company name" bar in browsers — that UI was removed by Chrome and Safari in 2019. Now offers no visible user benefit. For SEO and user trust: DV is sufficient, EV is a legacy carryover. Our checker treats all three equally.
SAN coverage — the field that trips up multi-domain sites
The Subject Alt Name (SAN) field lists every hostname the certificate is valid for. Modern certs use SAN for everything (the deprecated Common Name field is ignored by browsers). Common mistakes: 1. www vs naked — cert covers www.example.com but not example.com. Either add the naked as a SAN or configure the server to redirect naked → www before the TLS handshake (which requires the cert to still cover both, i.e. add the SAN). 2. Subdomain mismatch — cert covers *.example.com which matches api.example.com but not api.staging.example.com. Wildcards only cover one level. Fix by issuing a multi-domain cert or a wildcard for the specific level. 3. Ancient SAN limits — some cheap providers cap SAN counts. Modern CAs allow 100+. Let's Encrypt allows 100 SANs per certificate.
TLS 1.3, 1.2, and the versions to disable
The version negotiated during the handshake is on the server, not the certificate. TLS 1.3 (2018) is what you want: one round trip instead of two (faster page loads), forward secrecy always, and a shorter list of cipher suites (all strong). Most servers support it — enable it explicitly in your config. TLS 1.2 (2008) is still acceptable — it's what >99% of enterprise gear supports. Modern browsers still support it and Google doesn't penalize it. TLS 1.0 and 1.1 should be off. Browsers dropped support in 2020. PCI-DSS requires them off. If our checker reports TLS 1.0/1.1 negotiated, the server is configured to accept them — turn them off in the config (SSLProtocol / ssl_protocols setting) and re-run.
Mixed content — the reason your padlock is broken
A page can serve every byte over HTTPS and still be flagged as insecure — because it references a subresource over plain HTTP. That's mixed content, and browsers treat it in two tiers. Active mixed content (scripts, iframes, CSS, XHR, fetch, WebSocket) is blocked outright by Chrome, Firefox, Safari, and Edge — the request never fires, the feature breaks silently, and the console fills with errors. Passive mixed content (images, audio, video, favicons, media src) is loaded but the padlock is downgraded to "Not secure" and Chrome may auto-upgrade the request to HTTPS (failing if the origin doesn't support it). Common sources: (a) hard-coded CDN URLs that predate the HTTPS migration, (b) <img src="http://..."> from user-generated content or old blog posts, (c) analytics/tracking pixels from vendors that never upgraded, (d) legacy iframes to third-party widgets. This tool scans the rendered HTML and lists every offender by tag and URL so you can fix them in one pass. The quickest server-side fix: add Content-Security-Policy: upgrade-insecure-requests to force the browser to rewrite every HTTP URL on the page to HTTPS at request time.
HSTS + HTTP→HTTPS redirect — the invisible security layer
A valid certificate is not enough. If a user types http://example.com, the browser sends the first request unencrypted — an attacker on the same Wi-Fi can intercept it before the server has a chance to redirect. Two defenses stack: 1. Server-side 301 redirect from HTTP to HTTPS (this tool tests it) — closes the loop for every subsequent request. 2. HSTS (Strict-Transport-Security header) — after the first successful HTTPS visit, the browser refuses to speak HTTP to your domain for the header's max-age. This defeats the first-request downgrade attack from visit two onwards. To close the first-visit gap entirely, submit your domain to the HSTS preload list — Chrome and Firefox ship with the list baked in, so users are protected even on their very first visit. Requirements for preload eligibility: valid HTTPS everywhere, max-age >= 31536000 (1 year), includeSubDomains, and preload directive. This tool flags all four so you know exactly what to fix.
Auto-renewal — the single biggest cause of TLS outages
The most common TLS outage isn't a hack — it's a certificate that quietly expired because auto-renewal broke. Let's Encrypt certs are 90 days. The renewal cron ran fine for 400 days, then something changed (a config move, a firewall rule, a permissions issue), the renewal failed silently, and 30 days later the site went dark. Every operations team has seen this. Fixes: (a) run renewal at least 30 days before expiry so failures have time to surface, (b) monitor with an external check (this tool, or an uptime monitor with TLS support) that alerts at 30 days out, (c) log renewal attempts to a place someone actually looks, (d) test the renewal path quarterly by forcing a renew. Cert expiry is one of the few outages where the fix is trivial but the visibility is often zero.