SSL Checker

Test the certificate any public host actually presents: chain trust, hostname coverage, expiry countdown, key strength, and which TLS versions the server still accepts. Works on HTTPS and on mail ports: SMTPS, SMTP submission with STARTTLS, and IMAPS.

Try an example: google.com · expired.badssl.com · self-signed.badssl.com · smtp.gmail.com:587

Frequently Asked Questions

Common questions about reading a certificate check.

Both words point at the same thing. SSL is the old protocol name (dead since 2015), TLS is its successor, and "SSL certificate" stuck as the everyday term for the X.509 certificate both protocols use. There is no separate "TLS certificate" to buy.

This tool answers two different questions in one pass: is the certificate valid (chain, hostname, expiry, key), and which protocol versions the server agrees to speak (TLS 1.0 through 1.3).

Our take: when someone says "the SSL is broken", make them show you which of those two failed. The fixes live in different config files.

We validate against the CA store on this server. Browsers carry their own stores, and the sets differ. A cross-signed intermediate this server accepts can already be distrusted in Chrome or Firefox. OCSP revocation, Certificate Transparency requirements, and OS-level pinning also sit outside this check.

What to do: compare what the browser shows against the chain here:

openssl s_client -connect host:443 -servername host -showcerts

If the chains differ, the server is sending a different bundle to different clients, usually a CDN edge vs origin split.

Our host blocks outbound port 25, like nearly every hosting provider. It's the standard anti-spam measure, and it doesn't distinguish "probe the certificate" from "send mail". So an MX STARTTLS check from here would hang forever and lie to you.

The check takes one line from any machine that CAN reach port 25 (a mail server, a VPS with 25 open):

openssl s_client -connect your-mx-host:25 -starttls smtp -showcerts

Port 587 uses the same STARTTLS mechanism and usually the same certificate, so checking it here is a good proxy. It isn't proof, because the MX can be a different host entirely. Run the MX tool first to see which hostname actually receives your mail.

It's a warning, not a fire. TLS 1.0 and 1.1 were formally deprecated by RFC 8996 in 2021, and every current browser and mail client negotiates 1.2 or 1.3 anyway. A modern client never touches the old versions just because the server offers them. The risk is downgrade pressure on genuinely old clients, and audit findings.

You'll see it a lot: Cloudflare's default minimum is still TLS 1.0, and Gmail's mail servers accept it on purpose, because an encrypted delivery over TLS 1.0 beats a plaintext one.

Our take: on a website, raise the minimum to 1.2; it's one setting and nothing real breaks. On a mail server, think first: mail falls back to plaintext, not to an error, so cutting old TLS can make delivery less private.

Because they're usually different machines. Your website sits behind a CDN or web host with a certificate for example.com; your mail runs on mail.example.com or your provider's own hostname (smtp.gmail.com, *.mail.protection.outlook.com) with its own certificate.

Mail clients verify the hostname they were configured to connect to. If your users type mail.example.com but the certificate says server12.hostingco.com, every mail client shows a warning, even though "the SSL is fine" on the website.

What to do: check the exact hostname from your mail client's settings here, on the port it actually uses (587 or 993), not the website's.

No. SSL Labs runs a far deeper handshake analysis on port 443: cipher-by-cipher enumeration, downgrade attack tests, session resumption, CT log posture. If you need a hardening report for a website, use it.

What you get here that SSL Labs doesn't do: the mail ports. SMTPS on 465, STARTTLS on 587, IMAPS on 993. These are the certificates your users' mail clients actually verify, and they get the same checks as the web one.

Our take: for a website hardening report, use SSL Labs. For "why is Outlook warning about the certificate", start here.

🌐 Want the whole web layer (headers, redirects, HTTP/2) in one pass? Website Checker →

How this SSL checker works

Type a hostname, pick the service, and the checker opens a real connection from our server and completes a TLS handshake, the same thing a browser or mail client does. On port 587 it speaks SMTP first and upgrades with STARTTLS, exactly like an outbound mail client. It captures every certificate the server presents, validates the chain against the public CA store, checks the SAN list covers the hostname, and counts the days to expiry.

Then it goes back four more times, once per TLS version, and records which handshakes the server accepts. That answers the audit question "do we still allow TLS 1.0" without anyone reading an nginx config.

What "valid" means here

A certificate passes when all of these hold. Each one fails independently, and the chips tell you which: 

Chain trusted     →  a public CA vouches for it, no gaps, nothing expired mid-chain
Hostname covered  →  the SAN list includes the name you connected to
Not expired       →  today is inside the validity window (warn under 14 days)
Key strength      →  RSA 2048+ or a modern EC key
Signature         →  no SHA-1 anywhere browsers still look

Why the mail ports matter

Most "certificate expired" pain lands in mail clients, not browsers. Websites renew automatically these days; the certificate on the IMAP or SMTP endpoint is the one nobody watches until every phone in the company pops a warning. Checking mail.example.com:993 here takes ten seconds and uses the same verification path Outlook and Apple Mail do.

The one port we can't reach is 25, the inbound MX port. Our host blocks outbound 25 (nearly all hosting providers do), and a check that can't run should say so rather than guess. The result includes the one-line openssl command to run it yourself from a machine that can.

One vantage point, honestly labelled

The probe runs from the TamingDNS server. A GeoDNS-fronted host can present a different certificate per region, and a CDN edge can differ from the origin. If the result disagrees with what your machine sees, run DNS propagation on the hostname first. If resolvers return different IPs, you and this checker are talking to different servers, and both results can be true.