What does this tool check?

A TLS handshake to port 443 of the domain. We read the leaf certificate the server presents and surface: subject (whose name is on the cert), issuer (which CA signed it), validity window (valid from / valid to / days remaining), serial number, SHA-1 and SHA-256 fingerprints, key size, and the Subject Alternative Names (the full list of hostnames the cert covers).

The cert is 'Valid' but my browser still complains. Why?

A few common causes: the server did not send the intermediate chain (so the browser cannot link the leaf to a trusted root), the requested hostname is not in the cert's SAN list, the leaf is technically valid but expired in the chain above it, or your browser enforces stricter rules (Certificate Transparency, HPKP). The SAN list and chain status from this tool help you spot the SAN-mismatch case directly.

My cert says it expires in 7 days. Should I panic?

Yes, urgently. Below 30 days is risky, below 7 is emergency. If you use Let's Encrypt with certbot, run `certbot renew` (auto-renews 30 days before expiry by default). Also check that your CAA record allows the renewing CA, and that the renewal hook restarts the web server so the new cert is actually served.

HTTPS lives on 443 by convention, and that is where 99% of TLS cert problems matter. Custom-port TLS (8443, 9443) and protocol-specific TLS (IMAPS 993, SMTPS 465, etc.) are not supported by this tool. For those, use an OpenSSL command-line check (`openssl s_client -connect host:port -servername host`).

How do I use the SAN list?

Confirm every hostname you serve is actually in the cert. A common screw-up: cert issued for `www.example.com` only, then the apex (`example.com`) is left out. Visiting the apex then trips a hostname-mismatch warning. The SAN list shows you exactly what the cert covers.

Free, no signup, rate-limited per IP. Connection timeout 10 seconds. Private IPs (RFC 1918, localhost) refused for security.

WEB

SSL Certificate Checker

Check SSL certificate

Input

Verify SSL/TLS certificate validity, expiry date, and chain of trust. Essential for preventing "Connection Not Secure" warnings.

Terminal

Console ready. Execute a command to see output...

About SSL Certificate Checker

Secure the Lock

SSL/TLS certificates are the backbone of the encrypted web (HTTPS). A valid certificate ensures nobody is listening in on the connection.

What we check

Validity Dates: Has it expired? Is it valid yet?
Issuer (CA): Who signed it? (e.g., Let's Encrypt, DigiCert).
Chain of Trust: Is the intermediate certificate properly installed? (Common cause of mobile errors).

How to use SSL Certificate Checker

Enter the domain
Just example.com. No protocol prefix, no port. The check targets port 443 by convention.
Hit Check SSL
A TLS handshake runs from our server with the original hostname as SNI.
Read the report
Status (valid / expired / invalid), validity window, subject and issuer details, key size, SHA-1 and SHA-256 fingerprints, full SAN list.
Cross-check
Confirm every hostname you serve appears in the SAN list, then cross-reference with HTTP Headers for HSTS / CSP coverage.

Frequently Asked Questions

: A TLS handshake to port 443 of the domain. We read the leaf certificate the server presents and surface: subject (whose name is on the cert), issuer (which CA signed it), validity window (valid from / valid to / days remaining), serial number, SHA-1 and SHA-256 fingerprints, key size, and the Subject Alternative Names (the full list of hostnames the cert covers).