SSL Certificate Checker

What is this tool for?

The SSL Certificate Checker answers a question the browser leaves unanswered: is this HTTPS certificate valid, trusted, does it match the domain, and when does it expire? A browser shows "secure connection" or "your connection is not private", never the reason why.

The tool opens a real TLS connection to the host, inspects the server (leaf) certificate and the chain presented, then returns a verdict with discrete states. No "looks fine". An answer.

The difference with the address bar comes down to one point: the browser judges the connection as it sees it, after already patching a shaky chain behind the scenes. The checker judges the chain as the server actually serves it, the way curl, a remote API server, or a smartphone would see it. That honest view is what flushes out phantom failures.

Three uses that keep coming back:

• Before an incident: a certificate expires in eight days, no browser warning, total outage at the deadline. You see it coming.
• After a deployment: the site opens for you, but the partner's webhook returns a TLS error. Incomplete chain, almost always.
• During an audit: a 1024-bit RSA key or a SHA-1 signature lingering on an old internal service. The verdict points right at it.

How to read the verdict

The verdict fits in one coloured word, and that word is enough to decide. Here is how to decode it.

Below the verdict, the detail: expiry date and days left, the chain presented in order, the list of SANs, TLS version, cipher, key type and size, signature algorithm. Enough to diagnose, not just to observe.

One case is worth pausing on. Invalid does not always mean "broken certificate". When the only anomaly is a chain served incomplete, the message switches to a precise diagnosis: serve the fullchain. The certificate is fine; its delivery is what's wrong.

The real cases this tool flushes out

Incomplete chain: the server presents only the server certificate

This is the great classic. The server sends its server (leaf) certificate but forgets the intermediate that links it to the root. The result: the chain reaches no recognized authority, as served.

Chrome and Edge get by: they download the missing intermediate on their own (AIA fetching). The site "works for you". But curl fails, the mail client fails, the mobile app fails, the partner's HTTP library fails. A nightmare to diagnose without a dedicated tool, because the symptom depends on who is looking.

The fix is unique and unsurprising: serve the fullchain, that is, the server certificate followed by the intermediate(s), concatenated in the right order. Let's Encrypt hands you a ready-to-use fullchain.pem file directly.

# Count the certificates actually served
openssl s_client -connect captaindns.com:443 -servername captaindns.com -showcerts </dev/null 2>/dev/null | grep -c "BEGIN CERTIFICATE"
# Only 1 certificate = incomplete chain

One special case often passes for a tool bug: the server certificate served alone that still verifies. This only happens if that certificate was issued directly by a root, which the CA/Browser Forum now forbids. In practice, a public certificate served alone comes out invalid, and the recommendation is always the same: fullchain.

Expiry: the outage no browser announces

A certificate that expires in ten days triggers no warning. On the day itself, everything falls over. HTTPS blocked, API silent, webhooks in error, and support on fire.

The tool puts the expiry date and the days left at the top of the result. Below one month, it switches to a warning. But a snapshot does not warn ahead of time: for that, you need monitoring running in a loop (see below).

Hostname: the domain missing from the SANs

The certificate is valid and trusted, but it does not cover the requested name. Browsers ignore the old Common Name field: they read only the SANs (Subject Alternative Names). If the domain is not there, you get NET::ERR_CERT_COMMON_NAME_INVALID, whatever the CN says.

The most frequent trap is the wildcard. *.captaindns.com covers www.captaindns.com, but not the apex captaindns.com, nor a level deeper like a.b.captaindns.com. A wildcard only descends one notch. The fix: reissue, listing every intended name in the SANs.

Self-signed: encrypted, but without trust

A self-signed certificate has the same issuer and the same subject. It encrypts the connection, so data does travel safely. But no one vouches for who owns the key. The browser refuses and shows a warning.

Perfect for an internal service or a test environment. On a public site, it's a dead end: issue a free certificate via Let's Encrypt instead and automate it with ACME. The tool isolates this case in a separate verdict, so it isn't confused with a broken certificate.

Weak crypto: the fossils that linger

An RSA key under 2048 bits, an ECDSA key under 256 bits, a SHA-1 or MD5 signature: so many relics haunting old services that never got migrated. The browser may tolerate them for a while, but they are on borrowed time. The tool flags them on the server (leaf) certificate, before a client hardening gets them rejected overnight.

Automation and monitoring: the only sustainable strategy

Checking by hand is fine for a one-off incident. It does not hold up over time, and the calendar makes it unworkable.

The CA/Browser Forum is cutting certificate lifetimes in steps: 200 days in March 2026, 100 days in 2027, 47 days in 2029. At 47 days, renewing by hand becomes absurd. Two reflexes are in order.

Automate issuance with ACME. The ACME protocol (the one behind Let's Encrypt, via certbot, Caddy, Traefik, lego) renews and reinstalls the certificate with no human intervention. Set up once, forgotten afterwards. It's the only way to keep pace.

Monitor expiry continuously. Automation sometimes fails silently: issuance quota reached, DNS broken for validation, reload hook that never fires. Monitoring that checks expiry on a regular interval and alerts ahead of time catches those gaps. The CaptainDNS HTTP Uptime Monitor fills this role for your HTTPS endpoints.

This checker and the monitor complement each other: one diagnoses at a point in time, the other stands guard. To dig into the calendar and its consequences, read our guide on the reduction of certificate lifetimes to 47 days. And to move from a one-off check to a full approach (inventory, ACME automation, expiry monitoring), our guide on certificate lifecycle management lays out the method.

Web HTTPS only

This version covers web HTTPS: an implicit TLS connection over host:port, port 443 by default. Mail is out of scope. An SMTP server usually negotiates TLS afterwards, via STARTTLS, over ports 25, 587, or 465: a direct dial would see nothing there.

For a mail server's certificate, two tools take over: the SMTP/MX Tester inspects the certificate presented over STARTTLS, and the DANE/TLSA checker confirms that it matches the fingerprint published in DNS. Don't mix the two worlds: a web certificate and an MX certificate are not verified the same way.

FAQ - Frequently asked questions

Q: How do I check an SSL certificate online?

A: Enter the domain name in the host field and run the check. The tool opens a TLS connection to the host and port (443 by default), inspects the server certificate and the chain presented, then returns a verdict: validity, hostname match, system trust, expiry, and key and signature strength.

Q: What's the difference between server, intermediate, and root certificates?

A: The server (leaf) certificate carries your domain name. The intermediate links it to the root. The root (root CA) lives in the system trust store. The server must present the server certificate followed by the intermediates; the root does not need to be sent. That bundle is the fullchain.

Q: Why does my site work in Chrome but break everywhere else?

A: It's the symptom of a missing intermediate. Chrome and Edge fetch the absent intermediate on their own (AIA fetching), but curl, mail clients, and many mobile devices reject the connection. Serve the full chain (fullchain) to fix it everywhere.

Q: How long is an SSL certificate valid?

A: Up to 398 days today, but the lifetime is shrinking. The CA/Browser Forum mandates 200 days in March 2026, 100 days in 2027, 47 days in 2029. Let's Encrypt already issues 90-day certificates. At this rate, renewing by hand no longer holds: you have to automate via ACME.

Q: How do I monitor an SSL certificate's expiry?

A: This checker gives a snapshot. To be warned before an outage, plug in continuous monitoring with the HTTP Uptime Monitor: it checks expiry on a regular interval and alerts as the deadline approaches.

Q: What does a self-signed certificate mean?

A: Its issuer and subject are identical: it signed itself. It encrypts the connection but offers no public trust, hence the browser warning. Fine for internal use; for a public site, get a certificate issued by a recognized authority like Let's Encrypt.

Q: What do I do if the hostname doesn't match?

A: The requested domain is not in the certificate's SANs. Common case: a wildcard *.captaindns.com covers neither the apex nor a sub-subdomain. Reissue the certificate with every intended name in the SANs. The Common Name no longer counts: only the SANs are read.

Complementary tools

Useful resources

• RFC 5280 - X.509 certificate profile (certificate structure and validation)
• RFC 6125 - Hostname verification (SAN matching and wildcards)
• CA/Browser Forum - Baseline Requirements (issuance rules and lifetimes)
• Let's Encrypt documentation - Chain of trust (fullchain and intermediates)