SSL Certificate Check

Q: How long should my certificate validity period be?

Browser-trusted public certs are capped at 397 days (since 2020); most CAs issue for 90 days now to encourage automation. Long-lived certs are an antipattern — make renewal automated and frequent so the rotation pipeline is well-tested.

Q: Why do I have to renew every 90 days for Let's Encrypt?

Short-lived certs reduce the window of exposure if a private key is compromised, and they force you to automate renewal — if it's not automated, you'll fail one renewal and ship a cert outage. Let's Encrypt deliberately caps to 90 days to enforce automation discipline.

Q: What's the difference between SSL and TLS?

SSL is the original protocol (SSL 2.0/3.0, both deprecated). TLS (1.0, 1.1, 1.2, 1.3) is the standardised successor. People still say "SSL" colloquially, but every secure connection today is actually TLS. The certificate format (X.509) is shared.

Q: Should I use RSA or ECDSA for my certificate?

ECDSA is faster (smaller keys, faster handshakes, lower CPU on busy servers) and equally secure. RSA 2048 is universally compatible; some old clients (ancient embedded devices) don't support ECDSA. For modern web traffic, ECDSA. For maximum compatibility, dual-cert with both.

Q: Why does my self-signed cert show as untrusted?

Because the chain doesn't end at a CA your browser/OS trusts. Self-signed certs are valid cryptographically but no public root vouches for them. For internal use, distribute the self-signed cert (or your internal CA's root) to client trust stores; for public use, get a real cert.

Q: What's the difference between DV, OV, and EV certificates?

DV (Domain Validation) proves you control the domain — automated, free, dominant. OV (Organisation Validation) additionally verifies the organisation behind the domain — manual review, ~hours. EV (Extended Validation) is OV plus stricter review and used to trigger a green bar in browsers (deprecated UX). Browsers no longer differentiate them visually; DV is sufficient for almost every use case.

Q: What does "weak cipher suites" mean and should I worry?

We don't probe cipher suites in this tool. If you need a full TLS-security audit (cipher list, perfect forward secrecy, vulnerability scan), use a dedicated scanner like SSL Labs. Our tool tells you cert validity and chain trust, not cryptographic suite strength.

Q: My cert expires in 1 hour — what now?

Run the renewal manually right now. Most CAs (Let's Encrypt, ZeroSSL) can issue and deliver in under a minute. Get the new cert, deploy it, run the SSL check to confirm the new expiry date. Have someone else verify the actual user-facing site works. Then go fix whatever broke your automated renewal pipeline.

Inspect certificate validity, expiry, SANs, issuer and chain trust.

Result

No result yet

Enter the inputs above and press Run. Results appear here in a moment.

Monitor this 24/7 — get alerts on the first failure.

Start free

Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our Terms.

What is SSL Certificate Check?

SSL/TLS certificate checking verifies the certificate a host serves on port 443 — or wherever you've terminated TLS. The check answers questions like: "is it valid now," "how many days until expiry," "does the certificate chain build correctly to a trusted root," "does the certificate cover the hostname my users connect to." A misanswered cert question shows up in production as users staring at a giant browser warning.

This tool initiates a real TLS handshake against any host/port, captures the certificate the server presents, validates the chain against the standard CA bundle, and reports every property that matters for production operations: subject, issuer, validity window, SAN list, signature algorithm, key strength, TLS version negotiated, and chain trust status. Same answer the user's browser would compute, minus the scary UI when something's wrong.

How it works

Each check is a single TLS connection with detailed introspection:

1TCP connect to host:port — Default port 443. We support custom ports — useful for verifying TLS-on-non-443 services (LDAPS 636, IMAPS 993, MQTT-over-TLS 8883, internal services on 8443).
2TLS handshake with SNI — Send ClientHello with SNI (Server Name Indication) set to either the hostname you typed or the explicit server name override. SNI matters — many hosts serve different certificates depending on which name you ask for.
3Capture the certificate chain — The server sends its leaf certificate plus any intermediate CAs needed to build a chain to a public root. We capture the whole chain, not just the leaf.
4Validate against CA bundle — Standard validation: chain builds to a trusted root, certificate is currently within its validity window, the hostname matches a SAN entry, signature algorithm is acceptable. If any step fails, we report which step and why — not just a binary "invalid."

We don't probe for known TLS vulnerabilities or test cipher suites — that's a security scanner's job. We confirm "the cert your users will see when they connect right now is the cert you think it is."

When you'd use it

Pre-expiry warning

Run weekly against every public domain you operate. Anything under 30 days = scheduled action. Anything under 14 = drop-everything urgent. Browsers will turn red on expiry day; mobile apps that pinned certs will break.

Post-renewal verification

Renewed cert via Let's Encrypt / ACM / your CA. Run an SSL check — does the new cert show up? Does the chain build? If yes, the renewal deployed correctly. If still showing the old cert, your load balancer or reverse proxy hasn't reloaded.

Multi-domain SAN verification

Cert is supposed to cover app.example.com, api.example.com, www.example.com. Run a check per hostname against the same IP — confirm the SAN list includes each, the served cert is consistent across hostnames, and no hostname is silently serving a default cert instead.

Investigating browser "insecure" warnings

User reports a browser warning. Run the check on their URL. Compare against a known-good URL on your infra. Look at: chain build status (intermediate missing?), hostname match (SAN doesn't cover www.?), validity dates (expired? not yet valid?). Each failure mode in the tool maps directly to a browser warning category.

Internal service TLS audit

Internal services running TLS on non-standard ports (HAProxy admin on 8443, internal RabbitMQ on 15671). Use the custom-port option to verify each is serving the right cert with the right chain, before the next rotation surprise.

Reading the result

Days until expiry

Days remaining in the certificate's validity window. <14 days = urgent. Browsers show warnings at expiry. Some operating systems block connection at expiry+1d. Some apps with strict TLS pinning will refuse to connect days early.

Chain validity

Does the leaf chain to a trusted root? Three things can fail: (1) missing intermediate — server sent only the leaf, browsers can't fetch intermediate themselves reliably; (2) signature mismatch — chain links don't validate cryptographically; (3) untrusted root — the chain ends at a CA your browser doesn't trust (self-signed, internal CA).

Hostname match

Does the hostname you queried appear in the certificate's Subject Alternative Name (SAN) list? Modern certs ignore the deprecated Common Name field; only SAN counts. Wildcards (*.example.com) cover one level of subdomain (api.example.com matches, v2.api.example.com does not).

Signature algorithm

Modern: SHA-256 with RSA or ECDSA. Anything older (SHA-1, MD5) means the cert is so old that no modern browser will trust it. The algorithm tells you the cryptographic strength of the certificate itself, separate from the cipher suite used for the actual connection.

TLS version negotiated

1.3 is current and preferred. 1.2 is still acceptable. 1.0/1.1 are deprecated and rejected by most modern browsers — services still serving on them will show as "insecure" or fail to connect from current Chrome/Firefox/Safari.

Common pitfalls

Cert valid in our check, browser says "not secure"

Three usual reasons: (1) chain incomplete — server sent leaf only, our chain builder fetched intermediates from the cert's AIA extension while the browser couldn't; (2) cert is valid but the page mixes HTTP content (mixed-content warning); (3) HSTS preload mismatch — domain is in browser HSTS preload list but cert doesn't match expectations.

"Expires in 30 days" but my CA already renewed

Renewal happens at the CA — the new cert exists in your account. Until you actually deploy it to your server, the old cert is still the one users see. Confirm with the SSL check: if expiry date hasn't moved, deployment isn't done yet. Hit the deploy/reload pipeline.

Hostname mismatch on a `www.` prefix

Cert covers example.com but not www.example.com. Browsers will warn when users visit www.. Either: (1) reissue with both in SAN list, (2) configure HTTP redirect from www. to apex, (3) use a wildcard cert.

Different cert depending on SNI

Without SNI, hosts often serve a default fallback cert. If you're seeing the wrong cert, make sure your check is sending SNI for the hostname you care about. The custom "server name" field overrides what we put in the SNI extension.

Run SSL Certificate Check on every change, not just once.

Get alerts the moment something breaks — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 10 monitors. No card.