SSL Certificate Checker

TLS Certificates: What They Are and How to Check Them

A TLS certificate is the credential a server presents to prove its identity. It's the thing that makes HTTPS meaningful: without certificates, anyone in the middle of the connection could pretend to be your bank's server. With them, the bank's server proves possession of a private key matching a public key that a trusted Certificate Authority has signed off on. The system has flaws (CAs can be compromised, certs can be misissued) but it's the foundation of secure web communication. This tool lets you fetch and inspect any public domain's certificate, useful for debugging, auditing, and confirming deployments.

How TLS Authentication Works

When a browser connects to https://example.com:

1. TCP handshake: open the connection.
2. TLS ClientHello: browser sends supported protocols, ciphers, the hostname it wants via SNI.
3. TLS ServerHello + Certificate: server picks a protocol/cipher and sends its certificate (and chain).
4. Chain validation: browser verifies the certificate chain to a trusted root, checks dates, checks domain matches SAN.
5. Key exchange: TLS 1.3 uses (EC)DHE for forward secrecy.
6. Finished: encrypted application data follows.

The certificate proves the server holds the private key matching its public key, and a trusted CA has bound that public key to the domain.

What a Certificate Contains

Key fields to check:

• Validity dates, current time should be between Not Before and Not After.
• SANs, must include the hostname being accessed.
• Issuer, should be a CA your client trusts.
• Key size/algorithm, RSA 2048+ or ECDSA P-256+. Anything weaker is concerning.
• Signature algorithm, SHA-256 or better. SHA-1 has been deprecated.

Certificate Chain

A certificate is signed by an intermediate, which is signed by a root. Browsers trust ~100-200 roots out of the box (the "trust store"); intermediates aren't directly trusted but become trusted through chaining.

Typical chain:

Server must send leaf + intermediates in the handshake. NOT the root (browsers already have it; sending it wastes bytes and confuses clients). Misconfigured servers that send only the leaf cert work in some browsers (which cache intermediates) but fail in others.

Common Issues

"Your connection is not private" / NET::ERR_CERT_*

Expired certificate

The most common outage. Renewal failed (cron broke, account locked, payment expired, manual process forgotten). Fix: renew immediately; investigate why automation didn't.

Prevent with: monitoring (uptime services flag impending expiry), automated renewal (Let's Encrypt with certbot/acme.sh/Caddy), alerting (Pushover/Slack 14/7/1 days before expiry).

Missing intermediate

Server only sends the leaf cert. Some clients have the intermediate cached and work; others fail.

Diagnose: openssl s_client -connect host:443 -showcerts | grep -E "BEGIN CERTIFICATE", should show 2+ certs.

Fix: configure your TLS server to send the full chain. Most ACME clients handle this automatically; manual deployments need the chain file (e.g., fullchain.pem from Let's Encrypt).

Wrong cert presented (SNI mismatch)

Server hosts multiple sites; SNI (Server Name Indication) tells the server which cert to present. If SNI is missing or wrong, the server picks a default cert that may not match the hostname.

Diagnose: openssl s_client -connect host:443 -servername DESIRED_HOST vs without -servername.

Fix: configure server to require SNI; or use IP-based virtual hosts; or get a multi-SAN/wildcard cert covering all hosts.

Hostname not in SAN

Cert valid for example.com but accessed as www.example.com (or vice versa). Both must be in SANs.

Fix: reissue with all relevant SANs. Wildcards (*.example.com) cover one level of subdomain.

Mixed certificate chains

A new cert might be valid in CT logs but not yet trusted everywhere (CA's intermediate not in older clients). Less common with modern CAs (Let's Encrypt, etc.) but possible with newer CAs not yet in older Android/Java/Mac trust stores.

Certificate Types by Validation Level

DV (Domain Validation)

Cheapest, automated. Issued after proving control of the domain (DNS challenge, HTTP file challenge). What Let's Encrypt issues. Shows a padlock; that's it.

OV (Organization Validation)

Verifies the organization (legal name, address) in addition to domain. The cert includes O=Acme Corp. Browsers no longer show special UI for OV (used to). Mostly useless premium.

EV (Extended Validation)

Stricter org validation, sometimes face-to-face. Used to show a green address bar with company name; all browsers removed that UI in 2019-2020 because it didn't help users distinguish legitimate from phishing sites. EV certs still exist but offer no visible benefit over DV.

Reality: DV is fine for almost everyone. Pay for OV/EV only if you have a specific compliance requirement that says so.

Wildcard vs Multi-SAN

Multi-SAN: explicit list of domains. Better for static lists (example.com, www.example.com, blog.example.com).

Wildcard (*.example.com): covers any single-level subdomain. Better for dynamic subdomains (tenant1.example.com, tenant2.example.com, etc.).

Wildcard limitations:

• Only one level (*.example.com does NOT cover foo.bar.example.com).
• Doesn't cover the bare domain (*.example.com doesn't cover example.com).
• More security-sensitive (one private key covers many subdomains; compromise = all subdomains).

Often you want both: a SAN cert with example.com, www.example.com, AND *.example.com.

Certificate Transparency (CT)

Every cert from a public CA is logged in append-only CT logs run by Google, Cloudflare, Sectigo, etc. The certificate includes Signed Certificate Timestamps (SCTs) as proof of logging.

Why this matters for you:

• Audit your own certs: search crt.sh for your domain → see every cert ever issued for it.
• Detect misissuance: if a cert exists for your domain that you didn't issue, you have evidence a CA was tricked or breached.
• Monitor: services like Cert Spotter, Facebook CT monitor, or self-hosted crt.sh queries can alert you.

Caveat: internal/private CAs (your company's internal PKI) don't log to CT and don't need to.

Protocol and Cipher Considerations

A cert is necessary but not sufficient, protocol/cipher choice matters too.

• TLS 1.3: current best. Faster handshake, removed broken ciphers, forced forward secrecy. Use everywhere.
• TLS 1.2: still acceptable with strong cipher suites.
• TLS 1.1 / 1.0: deprecated, disabled by browsers since 2020.
• SSL 3.0 / SSL 2.0: ancient, broken (POODLE attack). Never use.

Cipher suite priorities (TLS 1.3 makes this much simpler, only ~5 modern AEAD ciphers).

For TLS 1.2, prefer:

• ECDHE key exchange (forward secrecy).
• AES-GCM or ChaCha20-Poly1305 (AEAD).

Test with SSL Labs (ssllabs.com/ssltest), gives a comprehensive report with grade. A or A+ is the target.

OCSP and Revocation

If a private key is leaked, the CA can revoke the cert. Two mechanisms:

• CRL (Certificate Revocation List): large file listing all revoked certs. Polled periodically.
• OCSP (Online Certificate Status Protocol): per-cert online check. Slow, latency-sensitive.
• OCSP Stapling: server fetches OCSP response, "staples" it to the TLS handshake. Fast and reliable.

Configure OCSP stapling in your TLS server config. Otherwise, browsers may either skip revocation checks (Chrome) or do slow client-side checks (Firefox).

HSTS, HPKP, and Beyond

HSTS (HTTP Strict Transport Security): response header forcing HTTPS-only:

After the first visit, the browser refuses HTTP forever (for the max-age). preload submits to the browser-shipped list, included by default. Protects against downgrade attacks.

HPKP (HTTP Public Key Pinning): deprecated. Caused too many outages from key changes. Browsers removed support.

Certificate Authority Authorization (CAA): DNS record listing which CAs may issue for your domain. CAs check before issuing.

Lightweight defense against CA misissuance.

Diagnosis Toolkit

• This tool, quick web-based inspection.
• openssl s_client, openssl s_client -connect host:443 -servername host -showcerts. Shows the chain, protocol, cipher.
• SSL Labs (ssllabs.com/ssltest), comprehensive grade and audit.
• crt.sh, search Certificate Transparency logs.
• testssl.sh, open-source script for thorough TLS testing.
• curl -v https://..., shows cert validation steps in verbose mode.
• nmap --script ssl-enum-ciphers -p 443 host, enumerate supported ciphers.

Privacy

The cert check fetches certificate data from public sources (the target domain's TLS endpoint via a CT log lookup like crt.sh). The domain you check is visible to that lookup service, like any DNS query or HTTP request to a public service. No browser fingerprinting, no analytics beyond the cert lookup itself. Because certificates issued by public CAs are CT-logged and public by design, what you find is public information; the only privacy consideration is "the lookup service knows you queried this domain." Open DevTools Network during use: one outbound request to the cert lookup endpoint, nothing else.