SSL/TLS Certificate Inspector
Inspect any HTTPS site's TLS certificate. Subject, issuer, SANs, key size, expiration, full chain.
What a TLS certificate proves
When you connect to an HTTPS site, the server presents a certificate signed by a trusted Certificate Authority (CA). The certificate binds a public key to a hostname, and the signature proves the CA verified that binding. Your browser checks the signature chain back to a root CA it trusts, and only then does it complete the TLS handshake.
Things to check on any certificate
- Expiration date — modern certs are 90 days (Let's Encrypt) or 1 year (commercial). If a cert is close to expiry on a production site, that's a renewal issue brewing.
- Subject (CN) and SANs — what hostnames this cert is valid for. The browser will warn if the hostname you're visiting isn't on the list.
- Issuer — which CA signed it. Let's Encrypt, DigiCert, Cloudflare, Sectigo, Google Trust Services are all common.
- Key algorithm and size — RSA-2048 is the floor; ECDSA P-256 is preferred (smaller, faster). RSA-4096 is fine but overkill for most uses.
- Signature algorithm — must be SHA-256 or better. SHA-1 was deprecated in 2017.
- Full chain — does the server send the intermediate certs? Missing chain breaks some clients (Java, older Android).
How TLS errors usually look
- NET::ERR_CERT_DATE_INVALID — the cert is expired (or system clock is wrong).
- NET::ERR_CERT_AUTHORITY_INVALID — self-signed cert, or chain doesn't lead to a trusted root.
- NET::ERR_CERT_COMMON_NAME_INVALID — the cert is for a different hostname.
- SSL_ERROR_BAD_CERT_DOMAIN — same as above (Firefox).
Why HSTS matters
If a site has a long HSTS policy (and you've visited it before), browsers refuse to load it without a valid cert — no "ignore warning and proceed" button. This protects against attacks that try to downgrade you from HTTPS to HTTP.