Live TLS certificate audit
Point this at a host and it reads the actual certificate sitting on port 443 right now. Not what your panel claims. The real one. You get validity dates, the issuer, the Subject Alternative Names, and whether the hostnames you expect are even covered. Plus a bit of HTTPS context. Honestly, the best time to run it is before a renewal or a CDN swap turns into a 2am browser warning nobody saw coming.
This reads whatever certificate the host hands back over TLS. It won’t replace a full chain or cipher scan, so don’t treat it as one.
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.
Common 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.
What is the difference between DV, OV and EV certificates?
It comes down to how hard the authority checked who you are, not how strong the encryption is. Domain Validated just proves you control the domain. Organisation Validated goes further and vets the actual company behind it. Extended Validation piles on the strictest checks of the lot. Here’s the part people get wrong: all three encrypt exactly the same. The only thing that moves is the identity assurance, and for most sites DV is genuinely fine.
