SSL Certificate Checker

What this check tells you

When you enter a host, we open a single TLS handshake to it and read the certificate the server presents — exactly what a browser does before showing the padlock. From that one handshake you get everything that matters: the validity window (certificates are only trusted between their notBefore and notAfter dates — expiry is by far the most common TLS failure in production), the issuer (which certificate authority signed it — Let's Encrypt, DigiCert, or the server itself, which is what "self-signed" means), the negotiated protocol version (TLSv1.3 is current; TLSv1.2 is fine; anything older is a red flag), the SHA-256 fingerprint for pinning and change-detection, and the subject alternative names — the actual list of hostnames the certificate covers. Modern browsers ignore the Common Name entirely and validate against SANs only, so a certificate whose SAN list doesn't include your hostname will fail even if the CN matches.

Checking WebSocket and non-standard endpoints

TLS is the same protocol whether the application on top speaks HTTP or WebSocket, so this tool accepts wss:// URLs as readily as https:// ones — a failing wss:// connection is very often just an expired or hostname- mismatched certificate, and browsers surface WebSocket TLS errors far less helpfully than page-load errors. You can also append a port (example.com:8443) to check API gateways, admin panels, mail servers speaking implicit TLS, or anything else listening off 443. Certificates on internal-style ports are the ones most often forgotten by renewal automation, which makes them worth checking before they page you at 3 a.m.

FAQ

How far in advance should I renew a certificate?

The tool flags anything under 30 days as "expires soon" — a sensible alarm threshold. With ACME automation (Let's Encrypt certificates last 90 days and renew at 60) you should never get near it; if you do, your automation is broken. Manually-managed certificates should be renewed at least two weeks out to leave room for validation hiccups.

Why does my site show "Not trusted" here but works in my browser?

The usual cause is a missing intermediate certificate: your server sends only the leaf, and browsers paper over it by caching or fetching intermediates on their own, while strict clients (and this checker) require the server to present the full chain. Fix it by deploying the "full chain" bundle your CA provided rather than the bare certificate.

Is a self-signed certificate ever okay?

For local development and closed internal systems where you control both ends and can distribute the certificate to trust stores — yes. For anything the public reaches — no: visitors get a full-page browser warning, and API clients must disable verification, which invites man-in-the-middle attacks. Publicly-trusted certificates are free via Let's Encrypt, so there's rarely a reason to ship self-signed to production.