How to use SSL Certificate Checker
What it does & when you need it
You point this checker at a hostname and it opens a TLS connection to port 443,
reads back the certificate the server presents, and lays out the parts that
actually matter: who issued it, which names it covers, and — the number most
people came for — how many days remain before it expires. It's the fast way to
answer "is my cert about to lapse?", "did my renewal actually deploy?", or "why
is this third-party API suddenly throwing certificate errors?" without cracking
open openssl s_client and squinting at the output.
Unlike the client-only tools on Devtools, this one cannot run in your browser — a web page can't open a raw TLS socket to an arbitrary host. So the hostname you type is sent to our server, which makes the connection on your behalf and returns what it saw. Nothing sensitive is involved (a public certificate is, by design, public), but it's worth being clear: this request leaves your device, unlike the JWT decoder, which does all its work locally.
How to use
- Type a domain into the Hostname field —
example.com, not a full URL. If you pastehttps://example.com/path, the scheme and path are stripped for you. Port 443 is assumed. - Press Check certificate or hit
Ctrl/Cmd+Enter. - Read the result card. A coloured badge summarises validity at a glance: green when there's comfortable runway, amber under 15 days, red when the certificate has already expired. Below it you get the issuer, the subject, the valid-from / valid-to window, the full Subject Alternative Name list, and the serial number.
Things worth knowing
The days-remaining number is the one to automate. A certificate's validity
window is stamped in at issue time — validFrom and validTo are fixed dates
that never move. Browsers and clients reject the certificate the instant the
validTo moment passes, with no grace period. That makes "days remaining" the
figure to watch: wire an alert that fires well before it hits zero (30 days is a
common threshold) rather than finding out from an outage.
SAN, not Common Name, is what gets checked. Modern browsers ignore the
legacy Common Name field and validate the hostname against the Subject
Alternative Name list. If the name you're visiting isn't in the SAN entries, the
connection fails even when the certificate is otherwise perfectly valid. Watch
out for wildcards, too: *.example.com matches api.example.com and
www.example.com but not the bare example.com, and it only covers a
single label — *.example.com does nothing for a.b.example.com.
The issuer tells you who to trust. The issuer field names the Certificate Authority that signed the certificate — Let's Encrypt, DigiCert, Google Trust Services, and so on. If the issuer is empty or simply points back at the subject itself, you're looking at a self-signed certificate: fine for internal testing, but public clients won't trust it without manual configuration.
We report what a browser would refuse to show. Because the check runs from our server rather than through a trust-enforcing browser, it reports the certificate even when it's expired, self-signed, or misconfigured — exactly the cases you're usually trying to diagnose. A browser would just throw an error page and hide the details.
Once you've confirmed the certificate, the DNS lookup tool helps verify the hostname resolves where you expect, and HTTP header inspector shows how the server behaves once the TLS handshake succeeds.