WEB
SSL Certificate Checker
Check SSL certificate
Input
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 the tool checks
- 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).
The certificate is the server's half of the handshake. The Client Hello your browser sends first also identifies the software making the connection, and that is what JA3 and JA4 fingerprints measure.
How to use SSL Certificate Checker
- Enter the domainJust
example.com. No protocol prefix, no port. The check targets port 443 by convention. - Hit Check SSLA TLS handshake runs from the packet.guru server with the original hostname as SNI.
- Read the reportStatus (valid / expired / invalid), validity window, subject and issuer details, key size, SHA-1 and SHA-256 fingerprints, full SAN list.
- Cross-checkConfirm 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. The tool reads the leaf certificate the server presents and surfaces: 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).
- 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.
- 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). - Confirm every hostname you serve is actually in the cert. A common screw-up: cert issued for
www.example.comonly, 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.