Every HTTPS site presents a TLS certificate as part of establishing a connection — this is what displays the padlock in the address bar. Under normal conditions this process is invisible. When it fails, every visitor sees a full-page browser warning with no way to reach the site through it. An SSL certificate checker makes the certificate's details visible in advance, before that failure occurs.
What Is SSL/TLS?
SSL (Secure Sockets Layer) was the original protocol for encrypting the connection a certificate secures. It had serious security flaws and was retired — every version of actual SSL has been disabled in every modern browser for years. TLS (Transport Layer Security) replaced it, and is what every HTTPS connection, and every certificate this tool checks, actually runs on today.
The name never caught up, though. What this tool checks — and what most people still call an "SSL certificate" — is technically a TLS certificate. There's no real SSL left to check anymore; "SSL Certificate Checker" means TLS certificate checker, same as "SSL" does everywhere else it's still said out of habit.
What that TLS connection actually does, once established:
- Encryption — data passing between browser and server is unreadable to anything intercepting it in transit (a network operator, a public Wi-Fi hotspot, anyone positioned between the two).
- Authentication — the certificate proves the server is actually who it claims to be, vouched for by a Certificate Authority the browser already trusts. This is what stops a connection from being silently redirected to an impostor server.
- Integrity — any tampering with the data in transit is detectable. A connection can't be quietly altered midstream without the browser noticing.
The certificate itself is the mechanism behind the authentication piece specifically — it's the credential a server presents to prove its identity, checked and validated as part of establishing the connection (the "handshake") before any actual page content is exchanged. Everything below is about that credential: what it contains, how to read it, and what goes wrong when it's misconfigured or expired.
Certificate Fields
- Expiry date — the most common cause of certificate outages. Free certificates from Let's Encrypt (issued via the ACME protocol, the most common setup in use today) are valid for 90 days; commercial certificates are typically longer, though industry rules have steadily shortened the maximum allowed lifetime over time. In either case, the certificate must be renewed before it lapses, typically through automation — which is where renewal failures most often originate.
- Issuer — the Certificate Authority (CA) that issued and vouches for the certificate. Browsers maintain a list of trusted CAs; a certificate from an unrecognized issuer triggers a "not trusted" warning even if the certificate is otherwise valid.
- Common name / covered domains (SANs) — the exact hostname or hostnames the certificate is valid for. A certificate issued for
example.comis not trusted forshop.example.comunless that hostname is explicitly listed as a Subject Alternative Name. - Signature algorithm — the cryptographic algorithm used to sign the certificate. Older, weaker algorithms are deprecated by browsers over time.
Why Certificates Expire by Design
Short lifespans are a deliberate security measure: they limit how long a compromised or misissued certificate remains trusted, and they enforce automated renewal rather than manual, easily forgotten renewal. The tradeoff is that automation failures — a renewal job that fails silently, or a DNS change that breaks ACME validation — result in outages more quickly than they otherwise would. Checking expiry proactively is preferable to discovering the problem through user reports.
Common Certificate Problems
- Certificate expired — the expiry date has passed. Requires immediate renewal.
- Name mismatch — the hostname being visited is not covered by the certificate. Commonly occurs after adding a new subdomain without updating the certificate's SAN list.
- Not trusted / self-signed — the certificate was not issued by a CA that browsers recognize. Expected and acceptable for internal tools; a genuine problem for anything public-facing.
- Expires soon — not yet an error, but worth addressing. A grade below the top rating on most checkers, including this one, indicates that renewal should occur before the certificate becomes urgent.
Interpreting Days Remaining
A certificate that is renewing correctly (Let's Encrypt's default behavior, for example) typically stays within a healthy range, renewing well before expiry on every cycle without requiring manual intervention. A certificate that has moved unusually close to its expiry date — within a week or two, when the normal renewal cadence would already have refreshed it — indicates that the renewal automation may have failed silently. This is worth investigating even though the certificate remains valid at the time of the check.
When to Check
- Before a domain migration or DNS change, to confirm the certificate will still validate afterward.
- After adding a new subdomain, to confirm it is covered by the certificate in use.
- Periodically for any domain without automated monitoring — a manual check costs little and catches renewal failures early.
- When a user reports a browser warning, to determine immediately whether the cause is expiry, a name mismatch, or a trust issue.
Because certificate validation depends on DNS resolving correctly first, a connection error rather than certificate details in the result usually warrants a DNS Lookup to rule out a resolution problem before assuming a TLS issue.
Frequently Asked Questions
Why do I need https:// entered without the protocol?
This checker handles the TLS connection directly, so it needs just the bare domain — enter it without https://. That's specific to how this particular tool is built, not a general rule about certificates.
My certificate is valid but the browser still shows a warning — why?
The certificate is usually only part of the picture. A mismatch between the hostname you're visiting and what's listed in the certificate's SAN list, an incomplete chain of trust (the server not sending its intermediate certificate), or a clock set wrong on the visitor's device can all trigger a warning even when the certificate itself hasn't expired.
How often does a certificate need to be renewed?
Let's Encrypt certificates, the most common setup today, are valid for 90 days and are meant to renew automatically well before that. Commercial certificates run longer, though industry-wide maximum lifetimes have been shrinking over time. Either way, renewal is expected to be automated — a certificate sitting unusually close to expiry usually means that automation failed silently, not that renewal is simply due.
Is a self-signed certificate a problem?
It depends on context. For an internal tool or a development environment, self-signed is normal and expected. For anything public-facing, it's a real problem — browsers won't trust it, and every visitor sees a full warning page.
Does one certificate cover all my subdomains?
Only if those subdomains are explicitly listed as Subject Alternative Names (SANs), or the certificate is a wildcard (e.g. *.example.com). A certificate issued for the bare domain doesn't automatically cover shop.example.com unless one of those applies.
Check any domain's certificate with the SSL Certificate Checker.