SSL Certificate Checker

Expiry countdown, chain details, protocol and SAN list for any HTTPS host.

Paste a hostname and we run the TLS handshake from outside your network, the same vantage point your visitors get, then hand back a verdict instead of a data dump: is it trusted, does it cover the name you typed, how many days until it expires, is the chain complete. When something's off, we name it in plain English and tell you the fix, because most certificate failures (a missing intermediate, or a name that isn't in the cert's SAN list) have a one-line answer. Expired and misconfigured certs still take real sites down all the time, almost always the one that slipped outside the renewal automation. Check yours a week before it's due, not the morning it breaks.

Queries run through the PacketNebula lookup service. We log nothing.

Fixing what it flags

Most of what breaks a certificate has a one-line fix, and the report above names which one you need. Chain incomplete: your server is sending the leaf but not the intermediate, so point it at fullchain.pem instead of cert.pem and reload. Hostname not covered: the cert is real but it does not list the name you typed, so reissue it with that name in the SANs (and remember a wildcard only covers one label, *.example.com matches api.example.com but not v2.api.example.com). Expiring: if renewal is a calendar reminder and a human with a pem file, replace that with ACME, because public certificates are heading toward 47-day lifetimes and manual renewal is already a losing game. Self-signed: fine inside a lab, never for the public web.

Check it from outside, not from your own box

The reason we run the handshake from our service and not your machine: your own monitoring has a talent for watching the wrong load balancer, and your browser hides missing intermediates with its cache. An outside handshake sees what a stranger's client sees, which is the only view that matters when a customer cannot reach you. Honestly, that gap between "works for me" and "works for everyone" is where most certificate incidents live.

Frequently asked questions

How often do certificates expire by accident?

Constantly, and at companies that should know better: expired certificates have taken down Microsoft Teams, Spotify and government portals. It is almost never ignorance. It is the one certificate that lived outside the renewal automation, on a load balancer or an internal API nobody owned. An outside check like this exists to catch that stray before your users do.

What does an incomplete chain mean, and why does the site still work for me?

Your server sent its own certificate but not the intermediate that links it to a trusted root. Desktop browsers often paper over it because they cached that intermediate from another site, so it looks fine on your machine while curl, mobile apps, Java clients and monitoring agents fail. The fix is server-side: serve the full chain (fullchain.pem, not cert.pem).

Is TLS 1.2 still acceptable?

Yes, with modern ciphers it is fine. TLS 1.3 is faster (one less round trip) and drops the legacy footguns, so turn it on if your stack allows, but sitting on 1.2 is not an incident. TLS 1.0 and 1.1 were deprecated by RFC 8996 and should be off.

Can I check a service that is not a website?

Yes, set the port. 8443 for alternative HTTPS, 993 for IMAPS, 465 for SMTPS, 636 for LDAPS. We do a TLS handshake with SNI on whatever port you give, so any TLS service works, not just web servers.

Is anything about my host stored?

No. The host you check is used for the one handshake and then discarded. We keep no history of what anyone looks up.