SSL Certificate Checker
We open a real TLS handshake against your hostname, walk the certificate chain, and grade the configuration the same way a browser would. Use it the day before an expiry, after migrating CAs, or when a user reports a 'Not Secure' warning you cannot reproduce.
Why SSL Certificates Are Critical for SEO
SSL encrypts data between your server and your users' browsers. Google prioritizes HTTPS websites in search rankings, and browsers display security warnings for HTTP sites, directly reducing traffic and conversion rates.
Common SSL issues we detect:
- Expiry: Certificates expire every 90 days (Let's Encrypt) or 1 year. Missing renewal causes instant downtime.
- Name Mismatch: Certificate doesn't cover your exact domain or subdomains.
- Untrusted CA: Certificate issued by an authority browsers don't trust.
- Weak Protocols: Using deprecated TLS 1.0 or 1.1 instead of TLS 1.2/1.3.
- Missing HSTS: Allowing insecure HTTP connections even when HTTPS is available.
How to read the report
The checker returns five blocks of information — treat them in order of user impact:
- Validity window.
Valid fromandvalid todates. Anything under 30 days should trigger action today, not next week. A negative remaining window means the certificate has already expired — every HTTPS visitor is seeing a browser warning. - Subject & SAN list. The
Subject Alternative Namelist is what actually determines which hostnames the certificate protects. A cert forexample.comwith nowww.example.comSAN will fail for the www subdomain even if it is otherwise perfect. - Issuer chain. You want a chain of at least two hops: leaf → intermediate → (root). A chain that ends with the leaf itself means the intermediate is missing from the server.
- Negotiated protocol and cipher. TLS 1.3 with AES-GCM or ChaCha20 is the healthy baseline. TLS 1.0 / 1.1 or RC4/3DES ciphers fail modern PCI-DSS scans.
- HSTS header. Without HSTS a user can still be downgraded to plain HTTP on first visit. A
max-ageof at least 15552000 (180 days) is the common recommendation for production.
Common issues and fixes
"ERR_CERT_COMMON_NAME_INVALID" for a subdomain
Your wildcard *.example.com only covers one level of subdomain, so api.v2.example.com is not matched. Either issue a second wildcard (*.v2.example.com) or reissue with explicit SANs for every subdomain that needs coverage.
Expiry passed despite auto-renewal
Renewal succeeded at the ACME level but the new certificate never reached the serving process. On Nginx: nginx -t && nginx -s reload. On a CDN: re-upload the PEM. On Kubernetes with cert-manager: confirm the Secret was updated and that Ingress rolled the pods.
Mixed content warnings despite a valid certificate
The certificate is fine; the page is loading an http:// asset (image, script, font). Browsers block this silently on modern sites. Grep the codebase for hard-coded http:// URLs and switch to protocol-relative or explicit https://.
Chain works on desktop, fails on Android 7
Older Android versions shipped without the newer ISRG Root X1 trust anchor. Serve the longer chain that ends in the DST Root CA X3 cross-sign, or bump your minimum supported Android version.
OCSP stapling flagged as missing
The server is not requesting or caching the OCSP response. On Nginx add ssl_stapling on; ssl_stapling_verify on; and point to a resolver. This shaves ~100ms off the first handshake and improves privacy.
What to do next
A clean report today is a snapshot. Certificates quietly rotate, renewal scripts silently fail, and CDN migrations sometimes revert HSTS settings. The three things worth automating after this check:
- Expiry alerts with at least 30/14/7-day lead time, so a stuck cron job does not become a Sunday outage.
- A post-deploy verification step that re-runs the SSL check against staging and production, failing the pipeline if the chain or protocol changes.
- Continuous external monitoring from FlashMon.app — it catches the cases where the server renewed but the load balancer did not, because the probe sees what your users see.
Never let your SSL expire again
Set up automated SSL monitoring and get alerts 30 days before expiry.
Frequently Asked Questions
SSL (Secure Sockets Layer) — technically superseded by TLS but still commonly called SSL — is a cryptographic protocol that encrypts data between a user's browser and your web server. Without it, sensitive data like passwords and payment information travels as plaintext, readable by anyone intercepting the connection. Beyond security, HTTPS is a confirmed Google ranking signal, and browsers like Chrome display prominent "Not Secure" warnings for HTTP sites, directly reducing user trust and conversion rates.
When a certificate expires, browsers immediately display prominent security warnings — "Your connection is not private" — blocking most users from reaching your site. HTTPS connections fail completely, causing instant downtime for all HTTPS traffic. Search engines may de-rank or remove affected pages from results. E-commerce sites lose sales immediately; SaaS applications become inaccessible to customers. Certificate expiration is entirely preventable with automated monitoring that alerts you 30+ days before the expiry date.
SSL and TLS are both cryptographic protocols that secure internet connections, but TLS is SSL's successor and significantly more secure. SSL 2.0 and 3.0 have known critical vulnerabilities and were deprecated long ago. TLS 1.0 and 1.1 are also deprecated by modern browsers. Current servers should use TLS 1.2 or TLS 1.3 — the latter offers better performance through a faster handshake and stronger encryption. When people say "SSL certificate," they technically mean a TLS certificate, but the terms are used interchangeably.
A certificate chain (or chain of trust) links your website's certificate to a root Certificate Authority (CA) that browsers inherently trust. The chain has three levels: your leaf certificate (issued for your specific domain), one or more intermediate certificates (issued by the CA), and the root certificate (pre-installed in browsers and operating systems). If any link in the chain is missing or incorrectly installed, browsers will reject the certificate even if it's technically valid. FlashMon's SSL checker verifies and displays the complete chain.
A correctly configured SSL setup shows: a valid certificate not near expiry, a trusted Certificate Authority in the chain, the domain name matching the certificate (including subdomains with wildcards), TLS 1.2 or 1.3 protocol, a strong cipher suite (AES-256 or ChaCha20), and HSTS header enabled. FlashMon's SSL Checker verifies all of these automatically and provides a Security Score out of 100, making it easy to identify misconfigurations before they trigger browser warnings or fail security audits.
Certificates should be renewed at least 30 days before expiry to allow time for DNS propagation, deployment testing, and handling unexpected issues. Many providers issue 90-day certificates (like Let's Encrypt) or 1-year certificates — with 90-day certs, the renewal process should be fully automated. Missing a renewal deadline causes immediate HTTPS failure across your entire site. FlashMon monitors your SSL expiry date continuously and sends alerts at 30, 14, and 7 days before expiry, eliminating the risk of a surprise outage.
Browsers on desktop often cache intermediate certificates from previous sessions on other sites, so they can still validate a chain even when the server does not send the intermediate itself. Mobile browsers, older Android devices, email clients, and non-browser HTTPS clients (curl, Go, Java) do not cache — they fail. If this tool reports an incomplete chain, concatenate the leaf and the intermediate(s) in the correct order in your server's certificate file (leaf first, root last, root optional). Re-test until the full chain is returned by the handshake itself.
A new certificate was issued, but the running web server process is still holding the old one in memory. Nginx and Apache need a reload (SIGHUP) to pick up new key material without dropping connections; HAProxy needs a reload as well. On a load balancer (ELB, Cloudflare, Fastly) you must re-upload the certificate to the balancer — renewing on the origin has no effect there. Always verify the served certificate after renewal instead of trusting the renewal log.
No. The Security Score rewards best-practice configurations: TLS 1.3, modern cipher suites, HSTS with a long max-age, OCSP stapling, and a valid chain. Losing points on OCSP stapling or a slightly older cipher suite is rarely user-visible. Losing points on chain issues, expiry, or hostname mismatch is. Treat the score as a prioritization guide, not a pass/fail grade — address red items first, yellow items during the next maintenance window.