SSL Certificate Checker
Check SSL certificate for any domain. View expiration date, issuer, certificate chain. Verify HTTPS security and get SSL rating
An SSL certificate is the difference between a green padlock and an "ERR_CERT_INVALID" that scares away every visitor. The interesting checks are not "is it valid" — every modern host gets that part right via Let's Encrypt automation — but is it expiring in three days, does the certificate chain match what browsers expect, does it cover www.example.com AND example.com, and is the signature algorithm one that 2026 browsers still trust. This checker fetches the certificate, walks the chain, and grades the configuration against current CA/B Forum guidelines.
What the check actually does
- Connect to the host via TLS, complete the handshake, capture the offered chain.
- Validate each certificate in the chain: not-before / not-after dates, signature algorithm, key strength, hostname match (SAN, not deprecated CN).
- Walk to a trusted root — does the chain terminate at a CA bundled in browser trust stores (Mozilla, Microsoft, Apple, Google)?
- Check OCSP / CRL revocation status (not all browsers do this; many short-circuit for speed).
- Detect common misconfigurations: missing intermediates, wrong hostname coverage, weak signature (SHA-1 in 2026, still appearing in legacy enterprise PKI), key reuse from before a rotation.
Working example
Input
Host: example.com:443
Output
Certificate: Subject: CN=example.com Issuer: CN=DigiCert TLS RSA SHA256 2020 CA1 Valid from: 2025-12-01 Valid until: 2026-12-01 (201 days remaining) Signature: SHA256-RSA (acceptable) Key: RSA 2048-bit (acceptable; ECDSA preferred for new certs) SAN: example.com, www.example.com OCSP stapling: enabled Chain: → example.com (leaf) → DigiCert TLS RSA SHA256 2020 CA1 (intermediate) → DigiCert Global Root CA (trusted) Grade: A + Modern signature algorithm + Valid chain to trusted root + Both www and apex covered ! Will require renewal within 201 days — verify ACME automation is configured
The "201 days remaining" sounds safe but consumer-grade TLS certs are typically 90-day or 1-year. Let's Encrypt is 90 days; commercial ones renew yearly. Set monitoring at ≤30 days remaining, not ≤7 — the renewal automation can break silently and you want a week of human-actionable warning, not 7 days.
The misconfigurations that bite
- Missing intermediate — browser-trusted root only signs intermediates, intermediates sign your leaf. Some servers serve only the leaf. Chrome and Firefox build the chain from a local cache and may "work" anyway; Safari and curl frequently fail. Always serve the full chain (server fullchain.pem).
- Hostname mismatch — cert covers example.com, you serve from app.example.com. Wildcards (*.example.com) cover one level only; app.api.example.com fails against *.example.com.
- Expired cert — every monitoring system catches this, but the alert often fires on the day-of-expiry, not in time to fix. Alert on ≤30 days.
- SHA-1 signature — browsers stopped trusting SHA-1 in TLS in 2017. Anything still using SHA-1 in 2026 is either ancient legacy infrastructure or misconfigured.
- Self-signed cert in production — fine for internal tools with a known trust path; fatal for anything public-facing. Browsers show a full-page warning.
- Mixed-content HTTPS — page loads over HTTPS but pulls scripts/images over HTTP. Browser blocks the resources (script-src, img-src) or shows "Not fully secure" warning. Audit with developer tools.
When to reach for this tool
- You added a new subdomain and want to verify the certificate covers it before pointing customers at the URL.
- You inherited a server and need to audit when each certificate expires before something breaks.
- You are migrating between certificate authorities (commercial to Let's Encrypt) and want to verify the new chain before flipping DNS.
- You are debugging "the API works in Chrome but curl says certificate verify failed" — usually a missing intermediate that Chrome's cache hides.
What this tool will not do
- It will not check private servers behind your firewall. The check has to be able to connect from the public internet. For internal-only services, run a local TLS scanner (testssl.sh, sslyze) inside the network.
- It will not test every TLS configuration option. Cipher suite ordering, TLS 1.0/1.1 fallback, OCSP must-staple — those require deeper tools. SSL Labs (ssllabs.com) does the comprehensive scan; this tool gives you the quick everyday checks.
- It will not validate certificate pinning. If your mobile app pins to a specific cert and you rotate, the app breaks even though the new cert is fine. Pinning audit is a separate concern.
Frequently asked questions
How often should I rotate my TLS certificate?
Automatically, well before expiry. Let's Encrypt issues 90-day certs and certbot auto-renews at 60 days. Commercial 1-year certs should be renewed at 11 months. Manual renewal is the bug; certificate expiry should be one of the most fully-automated parts of operations.
What is the difference between SSL and TLS?
TLS is the modern protocol; SSL was its predecessor. SSL 2.0 (1995) and SSL 3.0 (1996) are both broken and disabled in every modern browser. TLS 1.0 and 1.1 are also disabled (since ~2020). Current standards: TLS 1.2 (universally supported, fine for production), TLS 1.3 (newer, faster handshake, preferred). People say "SSL certificate" out of habit; the protocol in use is TLS.
Should I use ECDSA or RSA for my cert?
ECDSA for new certs. Smaller keys (256-bit ECDSA is ~equivalent to 3072-bit RSA), faster handshake, lower CPU on the server. RSA-2048 is still acceptable everywhere; use it only if you must support a client that does not handle ECDSA (genuinely ancient).
What does OCSP stapling do?
OCSP (Online Certificate Status Protocol) is how a client checks if a cert was revoked. Without stapling, the client makes a separate OCSP request per certificate — slow and a privacy leak (CA learns who visits your site). With stapling, your server includes a pre-fetched OCSP response in the TLS handshake. Free win; enable in nginx (ssl_stapling on) and Apache.
Why does my cert work in Chrome but fail in curl?
Two common causes: (1) missing intermediate cert in your server config — Chrome caches intermediates and rebuilds the chain; curl does not. Serve fullchain.pem. (2) System CA bundle out of date — common on long-lived CI containers. Update ca-certificates package.
Are wildcard certs (*.example.com) safe?
Functionally yes; security-wise debatable. If one subdomain is compromised and the private key leaks, every subdomain is exposed. For high-security environments, separate certs per service. For everything else, a wildcard simplifies operations and matches typical risk tolerance.
Related tools
Analyze X.509 SSL/TLS certificates. View issuer, validity, SANs, certificate chain. Check SSL certificate details. Free online certificate decoder
Build Content-Security-Policy headers visually. Add directives, sources, preview policy. Free online CSP generator for web security
Debug CORS issues, analyze headers, generate server configurations. Support for Express, Nginx, Apache, Django, Flask, Spring Boot. Learn CORS concepts. Free online CORS tester
Generate MD5, SHA-1, SHA-256, SHA-512 hashes from text or files. Verify file checksums. Free online hash calculator and checksum generator
Find your public IP address with geolocation, ISP, timezone info. Check IPv4/IPv6 address, hostname, browser details. Free online IP lookup tool
Last updated · E-Utils editorial team