What does an SSL checker verify?
An SSL checker opens a real TLS connection to a host and reads the certificate the server actually presents, rather than the one somebody believes was installed. The connection is made with verification on first — so a broken chain is detected the way a browser detects it — and, if that fails, a second connection is made with verification off purely so the certificate can still be described instead of being reported as a blank failure.
What it reports is the set of facts that decide whether a visitor gets a padlock: the issuer, the validity window and how many days are left, every name the certificate covers, the chain the server sent, the key type and size, the signature algorithm, the serial and the SHA-256 fingerprint. From those it answers the three questions that actually cause failures — is the certificate valid now, does it cover this hostname, and did the server send the intermediate certificate a client needs.
The chain check is the one people miss. A certificate can be perfectly valid and still fail for every visitor who has not cached the intermediate, because the server is sending only the leaf. It appears as an intermittent problem — fine on one machine, a warning on another — which is exactly the kind of thing that gets dismissed as a browser quirk. Counting the certificates in the chain settles it.
How to check a site's TLS certificate
- Enter the site address you want the certificate for, including the scheme. Enter the exact hostname a visitor types — `www` and non-`www` are different names, and a certificate that covers one may not cover the other.
- Press Check certificate. A TLS connection is opened to port 443, with SNI set to the hostname you asked for, and the certificate the server returns is read.
- Check the headline first: days remaining, or an expired date. Anything under three weeks should be treated as due rather than approaching.
- Work down the checks. A failed validity, hostname or chain check is a real problem for every visitor; a warning is something to schedule.
- Scan the name list. Highlighted names are the ones that cover the hostname you tested; the rest are the other names on the same certificate, usually the `www` variant, mail hosts and any other subdomains sharing it.
- Look at the chain as sent. One certificate in it means the intermediate is missing; two or more means a browser has everything it needs without fetching anything.
SSL check limits and rules
| Item | Limit |
|---|---|
| Connection | One TLS handshake to the host and port in the address (443 unless the URL names a port), with SNI set to that hostname |
| Verification | On first; a second unverified connection is made only to describe a certificate that failed, and the failure reason is reported |
| Checked | Expiry, not-yet-valid, hostname coverage (SANs and wildcards), self-signed, chain completeness, and the issuer |
| Reported | Subject, issuer, validity window, days remaining, SAN names, key type and size, signature algorithm, serial, SHA-256 fingerprint, and each certificate in the chain |
| Wildcards | `*.example.com` matches `shop.example.com` but never `example.com` or `a.b.example.com`, which is the rule browsers apply — not the looser one people assume |
| Rate limit | 40 checks per minute per visitor |
| Not included | Whether the site still upgrades HTTP to HTTPS, whether HSTS is set, and whether the TLS configuration is modern — the HTTP Header Checker covers the headers, and protocol and cipher preferences are not reported |
| Not verified | A certificate is served per handshake, so a load-balanced site may present a different certificate on another request; this reports the one this connection received |
When to use it
- Finding out how long is actually left on a certificate when the renewal reminder has been going to an address nobody reads.
- Confirming that a certificate covers both `example.com` and `www.example.com` before moving to a hostname that was never in the SAN list.
- Diagnosing the warning that appears on some machines and not others — an incomplete chain is the usual explanation, and the chain length shows it.
- Checking a wildcard certificate's scope: which subdomains it covers, and whether it is a wildcard at all.
- Recording the fingerprint and serial of the certificate currently deployed, so a renewal can be confirmed as live rather than assumed.
Is it private?
The certificate check is made by this site's server, for the same reason the header check is: a browser will not expose another origin's certificate details to page script. When you press the button, your browser sends the hostname to this site's own endpoint, which opens a TLS connection, reads the certificate, and returns the parsed details. The site you check sees a connection from this server and never learns who asked. The hostname and the certificate are not stored, and your IP is only counted against a per-minute meter.
Frequently asked questions
Browsers cache aggressively and forgive a lot. A chain problem only fails for a client that has never seen the intermediate, so it works on a machine that has visited the site before and fails on a fresh one — a cache, a new phone, a corporate proxy with a different trust store. Likewise, a hostname mismatch can be hidden by a redirect: a certificate for the wrong name usually still produces a padlock if the site redirects before the mismatch is a problem. This check reports the certificate that answered.
That the server sent its leaf certificate without the intermediate certificate that issued it. Most clients have the common intermediates cached, so it works for most visitors most of the time — and fails for the ones who do not. The fix is a server configuration change: point the certificate chain setting at the full bundle, not just the leaf file. It is the single most common cause of a padlock that is green for some users and not others.
`*.example.com` covers one label's worth of subdomains — `shop.example.com` yes, `example.com` itself no, and `a.b.example.com` no. A certificate with named SANs lists each hostname explicitly and can include any combination, including the bare domain and fully nested subdomains. Browsers enforce the one-label rule strictly, so a wildcard that looks like it should cover your hostname often does not.
Because that is now the norm. The maximum lifetime the public certificate authorities can issue has been coming down for years, and 90 days is the current ceiling for most, with shorter lifetimes being introduced for the highest-assurance automated issuers. Short lifetimes are only manageable with automation, so a certificate that is genuinely close to expiry usually means renewal is manual and overdue.
No, and it is not shown on purpose — reporting them reliably needs a client that can be told which protocol and cipher to offer, which PHP's stream layer does not do well. This tool reports the certificate the server presented, which is the part that produces the warning a visitor sees. Protocol and cipher configuration is a server-tuning question best answered with a dedicated scanner.
Yes, and it is worth knowing because it is easy to fix one and declare victory. A valid certificate gives you an encrypted connection, not a secure site: if the page is served over HTTP with no redirect, the padlock never appears; if it loads any subresource over HTTP, browsers downgrade it to not fully secure; and if HSTS is missing, the encrypted connection can still be intercepted on the first visit. The HTTP Header Checker covers the redirect and HSTS halves of that.
Related tools
Written and maintained by Md. Nur Hossain Repon.