Back to Tools
SSL Certificate & TLS Checker
Check SSL certificate validity, expiration, issuer, hostname match, chain, and TLS details.
Enter a domain name without protocol (e.g., google.com)
SSL Certificate for
X.509 Certificate Anatomy: Every Field Explained
An SSL/TLS certificate is an X.509 digital document that binds a cryptographic key pair to a domain name. Understanding each field helps diagnose browser warnings before they affect users.
| Field | Meaning | Common Issue |
|---|---|---|
| Subject CN | Common Name — the primary domain the certificate covers | Does not match the URL in the browser address bar |
| SAN (Subject Alternative Names) | All domains and subdomains the certificate is valid for | Missing SAN entries cause hostname mismatch errors even if CN matches |
| Issuer | The Certificate Authority (CA) that signed the certificate | Self-signed or untrusted issuer triggers NET::ERR_CERT_AUTHORITY_INVALID |
| Validity Period | Not Before and Not After dates defining the certificate's lifetime | Expired certificates trigger NET::ERR_CERT_DATE_INVALID; clocks must be synchronized |
| Serial Number | Unique identifier assigned by the CA | Used for revocation checking via CRL or OCSP |
| Public Key Algorithm | RSA (2048/4096-bit) or ECDSA (P-256/P-384) | ECDSA is faster but older clients (Android <7, Windows <7) may not support it |
| Signature Algorithm | How the CA signed the certificate (SHA-256, SHA-384) | SHA-1 signatures are deprecated and rejected by modern browsers |
| Certificate Chain | Server cert → Intermediate CA → Root CA | Missing intermediates are the most common cause of chain validation failures |
| OCSP / CRL | Revocation check endpoints | If OCSP responder is unreachable, browsers may fail open (soft-fail) or closed (hard-fail) |
How the TLS Handshake Works
Every HTTPS connection begins with a TLS handshake. Understanding this process helps diagnose connection failures, cipher mismatches, and performance issues.
- ClientHello: The client sends supported TLS versions, cipher suites, SNI hostname, and a random number. This is the first packet — if it does not reach the server, the handshake never starts.
- ServerHello: The server selects the highest mutually supported TLS version and cipher suite. It sends its certificate chain and its own random number. If the cipher suite list has no overlap, the handshake fails here.
- Certificate Verification: The client validates the server's certificate: checks the signature chain to a trusted root, verifies the hostname against CN/SAN, checks expiration, and optionally queries OCSP for revocation status.
- Key Exchange: RSA (encrypt pre-master secret with server's public key), ECDHE (elliptic curve Diffie-Hellman ephemeral), or DHE. ECDHE provides forward secrecy — past sessions cannot be decrypted even if the private key is later compromised.
- Finished: Both sides exchange MAC-verified "Finished" messages. Application data begins flowing encrypted with the negotiated symmetric cipher and session keys.
TLS 1.3 improvement: The handshake completes in 1-RTT instead of 2-RTT. The server sends its certificate encrypted on the first response, and the key exchange is limited to ECDHE and DHE only — RSA key exchange is removed entirely.
3 Common SSL/TLS Troubleshooting Workflows
BROWSER: NET::ERR_CERT_AUTHORITY_INVALID
- Check if the certificate is self-signed — public websites must use a trusted CA
- Verify intermediate certificates are installed and in the correct order
- Test with
openssl s_client -connect example.com:443 -showcertsto see the full chain - If using Let's Encrypt, ensure the ISRG Root X1 is trusted by the client (older Android may need the cross-sign)
Hostname Mismatch (ERR_CERT_COMMON_NAME_INVALID)
- The URL in the browser does not match any entry in the certificate's SAN list or CN
- Check both
example.comandwww.example.com— a cert for one does not cover the other unless both are in SAN - Verify you are not connecting via IP address — certificates are issued to domain names, not IPs
- Check that the SNI (Server Name Indication) field is being sent correctly
Incomplete Certificate Chain
- The server sent only the leaf certificate without intermediate CA certificates
- Download the intermediate bundle from your CA's website (often called
ca-bundle.crt) - Apache:
SSLCertificateChainFile /path/to/intermediate.crt(or concatenate with the server cert) - Nginx: concatenate server cert + intermediate into one file:
cat server.crt intermediate.crt > bundle.crt - Use the SSL Checker to verify the chain is complete after fixing
5 SSL/TLS Gotchas Every Sysadmin Should Know
1. Mixed content warnings: A valid HTTPS certificate does not prevent mixed content warnings. If your page loads images, scripts, or CSS over
http://, browsers block or warn. Use protocol-relative URLs (//cdn.example.com) or Content-Security-Policy upgrade-insecure-requests.2. HSTS preload consequences: Once a domain is on the HSTS preload list, every browser refuses HTTP connections. If your certificate expires and you cannot renew it, your site becomes completely unreachable. Always have monitoring and a backup certificate plan.
3. Wildcard certificate limitations: A
*.example.com wildcard covers www.example.com but not example.com itself. It also covers only one level — api.staging.example.com is not covered. Multi-level subdomains need explicit SAN entries or separate certificates.4. OCSP stapling timeout: If OCSP stapling is enabled but the OCSP responder is slow or unreachable, the TLS handshake can stall for seconds. Configure a reasonable timeout and test with
openssl s_client -status -connect example.com:443.5. Let's Encrypt rate limits: Let's Encrypt limits certificates to 50 per registered domain per week and 5 duplicate certificates per week. If your automation script fails and retries rapidly, you can hit the rate limit and be locked out for 7 days. Test in staging first.
CLI Equivalent
Use openssl s_client for the same certificate inspection from the command line:
# Check certificate details
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates -subject -issuer -fingerprint
# View full certificate chain
echo | openssl s_client -servername example.com -connect example.com:443 -showcerts 2>/dev/null
# Check TLS version and cipher
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | grep -E "Protocol|Cipher"
Related Tools
Common reasons: the certificate has expired, the hostname in your browser does not match any name in the certificate SAN list, intermediate certificates are missing from the server configuration, the certificate is self-signed and not issued by a trusted CA, or your system clock is significantly wrong.
A certificate chain links your server certificate through one or more intermediate CA certificates up to a trusted root CA certificate installed in every browser and operating system. Browsers need the complete chain to verify trust. If any intermediate is missing, the chain is broken and browsers show warnings.
A hostname mismatch happens when the domain name in your browser URL does not appear in the certificate Subject CN or SAN (Subject Alternative Name) list. For example, if your certificate covers only www.example.com but a user visits example.com without www, they get a mismatch warning.
Generate a new Certificate Signing Request (CSR), submit it to your CA for validation, download the new certificate and intermediate bundle, install them on your web server, reload the web server, and test with this SSL Checker to verify the new certificate is deployed correctly. If using Let's Encrypt, certbot renew handles this automatically.
TLS 1.2 and TLS 1.3 are the modern secure versions. SSLv2, SSLv3, TLS 1.0, and TLS 1.1 should be disabled — they have known vulnerabilities (POODLE, BEAST, CRIME). PCI DSS requires disabling TLS 1.0 and 1.1. Use the TLS Scanner to check which versions your server supports.