SSL Certificate Checker

How to Use This Tool

1. 1

   Enter the domain

   A bare domain or a full URL both work. Add a port for anything not on 443, as in example.com:8443.

2. 2

   Read the verdict and the days remaining

   Under 30 days means automated renewal should already have run. Under 7 means it has probably failed and needs looking at rather than waiting on.

3. 3

   Check the chain length

   A chain of one is the quiet problem. It usually means the server is not sending its intermediate certificate, which browsers often paper over and other clients do not.

4. 4

   Confirm the hostnames

   The certificate has to cover the exact name being visited. A certificate for example.com that omits www.example.com fails for half your visitors.

What a Certificate Actually Proves

Two things, and it is worth being precise because the padlock has been widely misread for years.

First, the connection is encrypted, so nothing between you and the server can read or alter what passes. Second, the server has demonstrated control over the domain name to whichever authority issued the certificate.

That is the entire claim. A certificate does not mean the site is honest, that the business behind it exists, or that anything on the page is true. Free certificates are universal and trivially obtained, which is exactly as it should be — encryption is infrastructure, not a trust badge — but it does mean a padlock on a phishing site is completely normal.

Browsers stopped presenting it as a trust signal for this reason. HTTPS is now the unremarkable default, and its absence is what gets flagged rather than its presence being celebrated.

Expiry Is a Renewal Problem

Certificate lifetimes have shortened steadily. Browsers cap trusted lifetimes at 398 days for anything issued since September 2020, and most certificates in practice run 90 days because that is what Let's Encrypt issues.

Short lifetimes make manual renewal impractical, so essentially everything is automated. Which means an expired certificate is almost never someone forgetting a date — it is a renewal job that has been failing silently for weeks.

The usual causes are a validation challenge that can no longer be served because the site's routing changed, an ACME client on a server that was rebuilt without it, a DNS provider whose API credentials expired, or a renewal that succeeded while the reload that would pick up the new certificate did not.

That last one is worth dwelling on: the certificate file on disk can be perfectly current while the server is still serving the old one from memory. The only way to know is to check what the server actually presents, which is what this tool does.

So the useful reading of a low day count is not "renew this" but "find out why the automation has not". Renewing by hand fixes today and leaves the same failure in place for the next cycle.

The Missing Intermediate

This is the failure that wastes the most time, because it presents as a problem that does not reproduce.

A certificate is not trusted on its own. It is signed by an intermediate certificate, which is signed by a root that browsers already trust. The server is supposed to send its own certificate plus the intermediates, so any client can build the path back to a root.

When the intermediate is missing, Chrome and Firefox will usually fetch it themselves and the site looks fine. Almost nothing else does. Mobile apps, curl, Java clients, payment gateways, webhook receivers and older Android devices all fail, and they fail with a generic certificate error that gives no hint the chain is short.

The result is a support ticket saying an integration is broken while the site loads perfectly for everyone testing it in a browser. A chain of one certificate in the panel above is what that looks like.

The fix is server-side configuration: serve the full chain file rather than just the certificate. Most ACME clients produce one, usually named fullchain, and pointing the server at the wrong file of the two is the single most common cause.

Which Hostnames a Certificate Covers

A certificate is valid for the names listed in it, and nothing else. Those live in the Subject Alternative Name list, which is what browsers check — the older Common Name field has been deprecated for hostname verification for years and is ignored when SANs are present.

The classic omission is www. A certificate covering example.com but not www.example.com produces a full-page warning for anyone who types or links the www form, and since both usually resolve, half your traffic can hit it.

Wildcards cover exactly one label. *.example.com matches www.example.com and shop.example.com. It does not match a.b.example.com, and — the part that surprises people — it does not match example.com itself. A wildcard certificate normally lists the bare domain separately for that reason, and one that does not is a certificate that fails on your homepage.

Protocol Versions and What to Care About

The protocol reported here is the one negotiated with this checker, which is the best version both sides support. It confirms the server can do that version; it does not prove the server has disabled the older ones. A dedicated TLS scanner is the tool for that question.

• TLS 1.3 — current, with a faster handshake and the legacy weak options removed from the protocol rather than merely discouraged.
• TLS 1.2 — still entirely acceptable and very widely deployed. Adding 1.3 alongside it is worth doing when the server supports it, mostly for the handshake speed.
• TLS 1.1 and 1.0 — deprecated in 2020 and refused by every current browser. A server negotiating one of these is effectively unreachable.
• SSL 2 and 3 — long broken. The name SSL persists in common use, but the protocol has been TLS since 1999.

HTTPS and Search

HTTPS is a Google ranking signal, and it is a very light one — described from the outset as a tiebreaker between otherwise comparable results. Moving a site to HTTPS does not lift rankings by itself.

What matters far more is what breaks when a certificate fails. A browser warning stops visitors before the page renders, and search engines will not index a page they cannot fetch securely. The cost is not a ranking adjustment; it is the site being unreachable.

There are two related setups worth checking alongside the certificate. HTTP should redirect to HTTPS in a single hop, and Strict-Transport-Security should be set so browsers stop trying HTTP at all — our HTTP Header Checker grades that header and shows the redirect chain in full.

The other is mixed content: an HTTPS page loading a script or stylesheet over HTTP. Browsers block those outright, which can break the page while the certificate itself is perfectly valid.

What This Cannot Tell You

It reports the certificate and the negotiated connection. It is not a full TLS audit.

It does not test which older protocol versions the server still accepts, enumerate supported cipher suites, check for known implementation vulnerabilities, or verify certificate revocation. Those need a dedicated scanner that probes the server repeatedly, which is a heavier thing to point at somebody else's infrastructure than a single handshake.

It also cannot tell you anything about the site behind the certificate. For that, our Indexability Checker covers whether search engines can use the page and the SEO Analyzer covers what is on it.

Frequently Asked Questions

Related Tools