Skip to content
AdminKit
Free tool Updated

SSL/TLS check: is a site's certificate and configuration healthy?

How does this check work, and what does the result tell you?

Shows a hostname's certificate subject, issuer, expiry date counted down in days, and the TLS protocol version and cipher the server negotiated with AdminKit's live Check API — a real TLS handshake, run the moment you submit, with no account needed, so an expiring certificate or a deprecated protocol version shows up before a visitor's browser throws a warning.

Part of the Security basics cluster — more tools, guides and terms on security basics.

AI explanation Run a check below, then sign in to ask AI to explain the result in plain language.

Next step

Check the same host's security headers, or see which ports are open on it.

Keep this result

Copy a link to this check so you can share it or run it again later. Want a heads-up when this result changes? Talk to our team and we'll set it up for you.

Set up alerts with our team

How it works and limits

An expired or misconfigured TLS certificate breaks HTTPS for every visitor with a full-page browser warning, and a site still accepting old, weak protocol versions or ciphers is a softer but real risk — both are easy to miss until a visitor or customer reports it.

What it checks

  • Completes a real TLS handshake to the hostname you enter and reads back the certificate presented: subject, issuer, the hostnames it covers (SAN), and its validity window.
  • Expiry date, counted down in days, so a renewal can happen before it lapses, and a flag if the certificate is self-signed (browsers will warn visitors).
  • Which TLS protocol version and cipher suite the server actually negotiated for this connection — TLS 1.3 and 1.2 are current, while TLS 1.0 and 1.1 are formally deprecated.

Limits

  • This runs one handshake using whatever protocol/cipher the server and this client both support — it does not try every possible protocol version or cipher suite to map everything the server is willing to accept.
  • It only reads the certificate the server presents for this connection; it does not independently validate the full chain to a root store the way a browser does.
  • The same TLS handshake this check performs also carries ALPN negotiation, deciding whether the connection runs HTTP/2 or HTTP/1.1 — this result doesn’t surface which protocol was negotiated, only the certificate and TLS version/cipher.

Check manually today

openssl s_client -connect example.com:443 -servername example.com </dev/null

This prints the certificate chain and the negotiated protocol/cipher. Look for Verify return code: 0 (ok) and a notAfter date far enough in the future; openssl x509 -noout -dates on the certificate output shows the dates more directly.

See how to read a TLS/SSL certificate check result for what each field in the chain means, and certificate transparency logs, explained for how a mis-issued certificate for your own domain would actually surface.

See best free SSL/TLS certificate checker tools for how this check compares to Qualys SSL Labs, Hardenize and ImmuniWeb’s SSL Test, all sourced from their own pages.

A valid certificate is about transport encryption, not whether your mail server actually enforces it — see does your mail server actually enforce STARTTLS? for that distinct check, and the glossary entry for STARTTLS.

The certificate this check reads back started life as a CSR (Certificate Signing Request) the server operator generated and sent to a CA — this tool shows the certificate the CA issued in response, not the request itself.

Frequently asked questions

Is this check live?

Yes — it runs a real TLS handshake against the hostname you enter via AdminKit's Check API (POST /v1/check/tls), the same endpoint anyone can call anonymously, rate-limited per visitor.

What can I check manually today?

openssl s_client -connect host:443 -servername host shows the certificate chain and negotiated protocol from the command line.

How do I know if the negotiated protocol is current or deprecated?

TLS 1.2 and 1.3 (RFC 8446) are current; TLS 1.0 and 1.1 are formally deprecated by RFC 8996. The result shows exactly which one was negotiated for this connection — it reports what the server and this check's client agreed on, not every protocol version the server might also accept.

Will it try to exploit a weak cipher or vulnerability it finds?

No — it only completes a standard TLS handshake to read the certificate and the negotiated protocol/cipher, the same information a browser already sees; it never attempts a downgrade attack or any other exploit.