SSL certificate checker

An SSL/TLS certificate is a cryptographically signed file that a server presents when a browser connects over HTTPS. It does two things: encrypts the traffic between the user and the server (so ISPs, Wi-Fi operators, and other middleboxes can't read or modify page content), and authenticates that the server actually owns the domain being requested. When the handshake succeeds, the browser shows the padlock; when anything is wrong — expired, wrong domain, untrusted issuer — Chrome and Firefox block the page with a full-screen warning that most users simply won't click through. Google has confirmed HTTPS is a (small) ranking signal, but the larger effect is on user trust: Chrome labels any non-HTTPS site "Not Secure" in the address bar.

What this tool checks

• HTTPS availability — whether the site responds on https:// at all
• Certificate retrieval — whether the full TLS handshake completes and the certificate is readable (catches broken chains, missing intermediates)
• Domain match — whether the certificate's Subject CN or Subject Alternative Names (SAN) cover the current hostname, including wildcard (*.example.com) resolution
• Self-signed status — whether the certificate was issued by a recognized CA or signed by the server itself (untrusted by browsers)
• TLS version — flags TLS 1.0 and 1.1 (deprecated by all major browsers in 2020); confirms TLS 1.2 or 1.3
• Expiry date — reports the exact expiry date, days remaining, and escalates severity as the cutoff approaches (under 30 days → attention, under 7 days → critical, expired → bad)
• Issuer — reports the CA (Let's Encrypt, DigiCert, Sectigo, etc.)

Why SSL matters for SEO

• Ranking signal — Google uses HTTPS as a lightweight ranking factor (confirmed publicly in 2014); all else being equal, the HTTPS version ranks above HTTP
• "Not Secure" label — Chrome, Firefox, and Safari all label HTTP pages "Not Secure" in the address bar; most users bounce before the page fully loads
• Form warnings — any password or payment field on an HTTP page triggers an additional explicit "Not secure" browser warning during input
• Expired cert = traffic loss — the full-page "Your connection is not private" warning blocks ~99% of visitors; an expired certificate on a busy site causes an immediate and severe traffic drop
• Referrer preserved — when an HTTPS site links to another HTTPS site, the Referer header is preserved; HTTPS-to-HTTP strips it, which affects analytics attribution

Good vs bad examples

Good — Let's Encrypt certificate covering apex and www, issued automatically via certbot:

Subject: CN=example.com
SAN: example.com, www.example.com
Issuer: Let's Encrypt
Expires: 2026-07-15 (82 days)
Protocol: TLSv1.3

Good — wildcard certificate covering all first-level subdomains:

Subject: CN=*.example.com
SAN: *.example.com, example.com
Issuer: DigiCert
Protocol: TLSv1.3

Bad — certificate expired (full-page browser block, ~99% bounce rate):

Subject: CN=example.com
Expires: 2025-11-02 (expired 23 days ago)

Bad — request to www.example.com but certificate only covers apex:

Subject: CN=example.com
SAN: example.com                    ← no www listed
Request: https://www.example.com/
→ Browser: NET::ERR_CERT_COMMON_NAME_INVALID

Bad — self-signed certificate on a public site:

Subject: CN=example.com
Issuer: CN=example.com              ← issuer == subject
→ Browser: NET::ERR_CERT_AUTHORITY_INVALID

Common mistakes

• Certificate covers apex but not www (or vice versa) — the most common "cert mismatch" error; fix by adding both domains as SANs when issuing (certbot: -d example.com -d www.example.com)
• Broken renewal cron — Let's Encrypt certs are 90-day and certbot renews at 60 days left automatically; if the cert is expiring anyway, the renewal timer is broken (check systemctl status certbot.timer or crontab -l)
• Missing intermediate certificate — the server sends only the leaf cert and not the intermediate chain; modern browsers fetch the intermediate via AIA, but some clients (curl, Java, older Android) fail. Fix by serving the full chain file (fullchain.pem from Let's Encrypt, not just cert.pem)
• TLS 1.0/1.1 still enabled — silently accepted by the server but rejected by current browsers; fix with Nginx ssl_protocols TLSv1.2 TLSv1.3;
• Self-signed cert in production — usually a leftover from a staging-to-prod deploy that didn't run the real certbot flow
• HTTP still accessible after HTTPS is set up — the SSL checker passes but the site serves duplicate HTTP and HTTPS content; use the HTTP → HTTPS redirect checker to catch this