Inspects the live certificate served on port 443 — expiry, trust chain and key. Try .
What the checker looks at — and what your browser hides
A green padlock tells you almost nothing. This tool reads the actual certificate your server presents and grades the four things that decide whether it keeps working: when it expires, whether the chain is complete and trusted, which hostnames it covers, and how strong the key is. Crucially, it reports what your server sends — not the forgiving version your own browser may have patched up from its cache.
Trust is a chain: leaf → intermediate → root CA → the browser’s trust store.
Expiry is the #1 cause of TLS outages
Nearly every certificate incident is a missed renewal. When a cert expires, browsers throw a full-page “Your connection is not private” warning and most visitors leave. With Let’s Encrypt issuing 90-day certificates — and the industry moving toward even shorter lifetimes — manual renewal isn’t viable. The fix is ACME auto-renewal plus monitoring; this checker is how you spot a cert drifting toward expiry before it bites.
The missing-intermediate trap
The most common silent misconfiguration is a server that sends only the leaf certificate, not the intermediate(s) above it. Desktop Chrome often hides this — it caches or fetches intermediates — so it “looks fine” to you. But stricter clients (mobile apps, API consumers, mail servers, payment terminals) can’t build the chain and fail. This tool shows the full chain it received and warns when the intermediate is absent, so you catch the problem your browser is covering for.
Coverage and key strength
A certificate only secures the hostnames listed in its Subject Alternative Names, so a cert for example.com won’t cover www.example.com unless both are listed — the tool shows the SANs. For keys, 2048-bit RSA is the floor and ECDSA P-256 is a strong, modern choice; only genuinely weak keys are flagged. Pair this with the WHOIS lookup (domain expiry) and the Email Security Checker for the full picture of a domain’s health.
🔒 Tired of cert fire-drills? Servnet manages TLS certificates, full chains and auto-renewal across your whole estate. See managed security →
SSL certificate checks — common questions
What does the SSL certificate checker do?
It connects to your site on port 443, reads the exact TLS certificate the server presents, and reports the essentials: how long until it expires, whether the trust chain is complete and browser-trusted, who issued it, which hostnames it covers, and the key type and size. Each is graded pass / warning / fail with the fix.
How do I check when an SSL certificate expires?
Enter the hostname and read the validity bar and the “days remaining” figure. We flag anything under 30 days as a warning and under 15 days (or already expired) as a failure. An expired certificate triggers a full-page browser security warning, so this is the check to automate.
What is the certificate chain, and why does a missing intermediate matter?
Browsers only trust your certificate if they can build an unbroken chain from your site’s “leaf” certificate, through one or more intermediate certificates, up to a root CA already in their trust store. If your server sends the leaf but omits the intermediate, many browsers cope (they cache intermediates) but some clients — APIs, older devices, mail servers — fail with a trust error. The tool shows the full chain it received and warns if the intermediate is missing.
My browser says the site is secure — why does this tool flag it?
Browsers are lenient: they cache intermediates and sometimes fetch missing ones automatically, so a chain that’s technically incomplete can still look fine in Chrome. This checker reports exactly what your server sent, which is what stricter clients (and security scanners) actually see — so it can surface a problem your browser quietly papers over.
What key strength should a certificate use?
2048-bit RSA is the minimum; 1024-bit is obsolete and flagged. ECDSA (elliptic-curve, e.g. P-256) keys are short but strong and increasingly common — a 256-bit ECDSA key is fine. The tool reports the key type and size and only warns on genuinely weak keys.
Does it work for mail servers and other TLS services?
This tool checks HTTPS on port 443, which covers websites. The same certificate is often reused for mail, but mail-specific TLS (and MTA-STS enforcement) is best confirmed with the Email Security Checker. For a non-standard HTTPS port, check the service directly.
Why automate certificate renewal?
Most outages from certificates are simply forgotten renewals. Short-lived certificates (Let’s Encrypt issues 90-day certs, and the industry is moving shorter) make manual renewal impractical — use ACME auto-renewal and monitor it. Servnet manages certificates and renewals across estates so none lapse.