How to Check a Website's SSL Certificate

Check an SSL certificate before it bites you

An SSL/TLS certificate is what turns http:// into https:// and puts the padlock in the address bar. When it's healthy, nobody notices. When it expires, is issued to the wrong name, or uses a weak setup, visitors get a full-screen browser warning and most of them leave immediately. Search engines and payment providers care too.

You'll want to check a site's SSL certificate in a few situations: right after launching or migrating a site, when you're about to let a certificate auto-renew (or worried it didn't), when a browser throws a "Not Secure" or "NET::ERR_CERT" warning, or when you're auditing a domain you don't control. This guide walks through reading the important certificate fields with a free SSL certificate checker, then confirming the live certificate straight from your browser so you're never guessing.

How to check a website's SSL certificate

1. Open the SSL checker. Go to the SSL checker tool. It runs in your browser — no account, no install, and nothing about your own machine is uploaded.

2. Enter the domain. Type the hostname you want to inspect, like example.com. You can paste a full URL (https://example.com/page) and the tool strips it down to the hostname automatically. Check the exact hostname people visit — www.example.com and example.com can have different certificate coverage, so test both if you're unsure.

3. Run the check and read the headline. Start the check and look at the top result first: is the certificate valid, and how many days remain until it expires. Expiry is the single most common cause of outages, because certificates are short-lived now (often 90 days) and silent auto-renewal occasionally fails. Anything under ~30 days is a "go look at your renewal" signal; a negative number means it has already lapsed.

4. Confirm the issuer and the name match. Check the issuer (the certificate authority, e.g. Let's Encrypt or DigiCert) and the Subject Alternative Names (SAN) list. The domain you typed must appear in that SAN list — that's how the browser decides the certificate actually belongs to this site. A missing or mismatched name is exactly what produces a CERT_COMMON_NAME_INVALID error.

5. Review the chain and the crypto. Walk down the certificate chain from the leaf (your domain) up to the root. A broken chain — a missing intermediate certificate — is a classic gotcha that works in some browsers and fails in others. Then glance at the protocol/TLS version, key size, and signature algorithm. You want a modern TLS version and a strong key; flagged items and the overall grade tell you where to focus.

6. Note HSTS and any warnings. The result also flags whether HSTS is enabled and lists any specific issues (mixed content, weak ciphers, and similar). Treat each warning as a to-do item rather than a pass/fail.

7. Verify against the live certificate in your browser. For the authoritative, real-time certificate, open the site in Chrome or Firefox, click the padlock (or the tune/site-info icon) in the address bar, choose "Connection is secure" then "Certificate is valid," and read the Valid from / Valid to dates, Issued to, Issued by, and SAN fields directly. This is the ground truth straight from the server, and it's a good habit to cross-check the fields you reviewed in step 3 through 5.

8. Re-check after any fix. After renewing a certificate, adding a missing intermediate, or redirecting http to https, run the check again so you can see the new expiry date and a clean result.

Tips and common problems

• "Valid but still warned" usually means the chain. If a certificate looks fine on the leaf but some visitors get errors, suspect a missing intermediate certificate. Re-deploy the full chain (often called the "fullchain" file) on the server.
• One certificate, many subdomains. A wildcard certificate (*.example.com) covers one level of subdomain only. blog.example.com is covered; a.b.example.com is not. Check the SAN list rather than assuming.
• Mixed content breaks the padlock. A page can serve over HTTPS while still loading an image or script over plain HTTP, which downgrades the lock. Fix those resource URLs to https://.
• The certificate is fine but HTTP isn't redirecting. Plenty of "no padlock" complaints are really a redirect problem, not a certificate problem. Confirm http:// forwards to https:// with the redirect checker.
• Renewed but the old cert still shows. Caching, a CDN edge node, or a load balancer can serve a stale certificate. Give it time, purge the CDN, and verify the date moved.

FAQ

Does this tool read the real certificate from the server? The browser-based checker is built to walk you through the certificate fields and what they mean, and it runs entirely on your device with nothing uploaded. For the live, authoritative certificate exactly as the server presents it right now, use the browser padlock method in step 7 — that's the source of truth, and it takes about ten seconds.

How often should I check a website's SSL certificate? If you rely on auto-renewal, a quick look once a month is plenty, plus an immediate check after any DNS, hosting, or domain change. If you renew manually, check a week or two before the expiry date so you have time to act.

What's a safe number of days remaining before I worry? There's no hard rule, but treat anything under about 30 days as your cue to confirm renewal is set up and working. Modern certificates expire fast, so the buffer protects you against a single failed auto-renewal.

The certificate looks valid but the site is still "Not Secure" — why? The three usual suspects are a missing intermediate (broken chain), mixed HTTP content on an HTTPS page, or HTTP not redirecting to HTTPS. Check the chain and warnings here, then confirm the redirect behavior separately.

For a wider security and SEO pass, pair this with the security headers checker, inspect raw responses with the HTTP headers tool, confirm where the domain points using DNS lookup, and see how HTTPS fits the bigger picture in the technical SEO guide.