SSL Certificate Checker
Read the live TLS certificate a host serves: expiry, issuer, subject, SAN coverage and your expected hostnames.
This SSL certificate checker reads the actual TLS certificate a host serves on port 443 right now, not whatever your control panel claims is installed. Enter a hostname and it pulls the validity window, the days remaining before expiry, the issuer and subject fields, and the Subject Alternative Names the certificate really covers, then checks those against the hostnames you expect so a covered apex with an uncovered www never slips through. It adds a light HTTPS context read too, so you can see whether the host answers and whether HSTS showed up on that sampled response. Run it right after a hosting move, a DNS change, a reverse proxy going live or a CDN switch, the moments when one layer looks fine while the layer underneath still serves a stale or wrong certificate. For full chain and cipher work, follow up with a dedicated TLS scanner.
Queries run through the PeopleAreGeek lookup service. We log nothing.
What this SSL certificate checker is for
Your control panel can swear up and down that a certificate exists. The browser doesn't care. It only looks at what's actually served for the exact name someone typed. So a live check earns its keep right after the messy moments: a hosting move, a DNS change, a reverse proxy going live, a CDN flicking on, a fresh subdomain, an auto-renewal that may or may not have fired. The trap is that one layer looks perfectly fine while the layer underneath is still handing out a stale or wrong certificate.
What you get here is the stuff that actually decides your next move. Validity window. Days left. Issuer, subject, the SAN names, and whether the hostnames you expect are really covered. There's a light HTTPS context check too, so you can tell if the host even answers and whether HSTS showed up on that one sampled response. For the deep TLS protocol, chain and cipher work, run a dedicated external scanner as a second pass. I wouldn't lean on this for that.
How to read the result
- Days remaining is your runway. How long before this thing expires and someone gets paged.
- Valid from and valid to are the window the server reported back, start and end.
- Issuer is the certificate authority, or whatever issuing-chain label the parsed cert exposes.
- Subject carries identity fields, but here's the thing: modern hostname matching mostly ignores it and leans on the SAN names instead.
- SAN coverage shows which hostnames the cert says it covers. Wildcards included, when there are any.
Hostname coverage is where many SSL mistakes hide
A cert can be totally valid and still flat-out wrong for the name a visitor opened. Happens all the time. The apex domain is covered but www isn't. A shiny new subdomain points at the right box yet serves a cert that was only ever issued for the old site. And wildcards fool people: one can cover a single label like app.example.com while doing nothing for a deeper name like api.app.example.com. Checking the names you expect before you flip the switch costs you a minute. Chasing browser warnings afterward, with users watching, costs a lot more.
Renewal timing and operational habits
Don't wait for the last day. Please. For anything that matters in production, the websites, the APIs, the admin domains, give yourself a 30-day buffer. That window is what catches the stuff that quietly breaks: a DNS validation that won't pass, a CDN swapping its edge cert under you, an account nobody can log into anymore, automation that died three months ago and nobody noticed. And when a cert is getting close, ask the boring questions. Who actually owns the renewal? Is auto-renew even on? Which challenge path is it using? If all of that falls over, is there a manual fallback, or are we improvising?
Common SSL certificate checks after changes
- Retest the exact hostname once DNS has propagated. The root domain alone isn't enough.
- Retest after you turn a CDN on or route around it. The edge cert and the origin cert don't always match.
- If both apex and www stay public, test both. People forget the one they don't use.
- Once HTTPS is steady, look at the HTTP headers so HSTS and redirects are something you chose, not something that happened.
- And keep expiry monitoring in its own lane, separate from the one-off debugging you do today.
Frequently asked questions
Does a valid certificate mean HTTPS is fully secure?
No, and it's worth being clear about that. A valid cert proves one important piece of the TLS path, the encryption and identity bit. Everything else is still on you. App bugs, weak auth, mixed content loading over plain HTTP, missing security headers, a sloppy server config. The padlock is a start, not a finish line.
Why does the subject differ from the hostname?
Because these days the subject mostly isn't where the names live. Modern certs lean on Subject Alternative Names for hostname coverage, and the common name in the subject is almost a leftover. So read the coverage table. Don't assume the subject CN is telling you the whole story, because it usually isn't.
Can this checker inspect certificate chains and TLS versions?
Not right now, no. The live endpoint pulls the served certificate summary plus the HTTPS context, which is enough to act fast and catch the obvious stuff. When you genuinely need the full chain or the exact protocol versions, reach for a dedicated TLS scanner. Different job.
What does this certificate checker verify?
It reads the certificate your server actually hands out. You see the issuer, the validity dates, which hostnames are covered, and how many days are left before it expires. Real served data, not whatever a dashboard claims somewhere upstream.
Why does my certificate show as untrusted?
Nine times out of ten it's a missing intermediate certificate in the chain. The server forgot to send it. After that the usual suspects are a self-signed cert, one that's already expired, or a plain name mismatch where the cert doesn't list the host you asked for. Look at the chain first, honestly. That's where it usually hides.