SSL Checker — Test Any Site's HTTPS Certificate
Expiry, trust, covered names and the full chain — including certificates your browser refuses to show you.
🔗 Our server performs the TLS handshake and reads the certificate — including expired and self-signed ones your browser would simply block. Nothing is sent to the site beyond the handshake. Results are cached for 10 minutes. Limited to 15 checks per minute.
Certificate
Covered names (SAN)
Chain
Check any site's SSL/TLS certificate: whether it's trusted, when it expires, which names it covers, who issued it, and the certificate chain behind it — with a plain-language verdict on top.
Because the handshake runs from our server with verification deliberately relaxed on the inspection pass, this tool can show you broken certificates too — expired, self-signed, or issued for the wrong name — which is precisely when your browser shows a warning page instead of the details you need.
How to use SSL Checker
- Enter a hostname like example.com. No https:// needed.
- Click Check certificate. The verdict line says whether browsers will accept it, and why not if they won't.
- Check the days-left tile — amber under two weeks, red past expiry.
- Review the covered names and chain when debugging a mismatch or trust problem.
The four ways certificates fail
- Expired. The most common and most visible failure — every browser blocks the page. Certificates now last at most ~13 months, so renewal is a recurring event, not a one-off.
- Wrong name. The certificate is valid but doesn't list the hostname being visited. Classic case: it covers
example.combut notwww.example.com, or a wildcard*.example.combeing expected to covera.b.example.com— wildcards only span one label. - Untrusted chain. Usually a server that sends its own certificate without the intermediate. Desktop browsers often paper over it with cached intermediates; strict clients — curl, mobile apps, payment webhooks — fail. If this tool says untrusted but your browser is happy, this is almost always the story.
- Self-signed. Fine on an internal service where you distribute the certificate yourself; meaningless on the public web, where trust comes from a CA.
Reading the chain
A working chain runs leaf → intermediate(s) → root: your certificate is signed by an intermediate, which is signed by a root that ships with browsers. The server should send the leaf and intermediates; the root lives on the client. If the chain list here is just one certificate and the verdict says untrusted, the server is missing its intermediate — on most stacks that means using the "full chain" file the CA gave you, not the certificate alone.
Let's Encrypt and short renewals
Free 90-day certificates renewing automatically are now the web's default. The failure mode isn't cost — it's a renewal cron that silently broke months ago. A certificate from a free CA with under two weeks left deserves a look at whatever was supposed to be renewing it.
Related checks
The header checker grades the HSTS header that makes HTTPS stick; the DNS lookup shows CAA records restricting which CAs may issue for the domain.
Frequently asked questions
My browser says the site is fine but this tool says untrusted — who's right?
Both, which is the problem. Desktop browsers cache intermediate certificates from other sites, so they can quietly repair a server that fails to send its own intermediate. Strict clients — curl, mobile apps, webhook senders — can't, and fail. If this tool says untrusted, fix the server's chain (use the CA's full-chain file) even though your browser looks happy.
How often do certificates need renewing?
Publicly trusted certificates are capped around 13 months, and the free CAs issue for 90 days with automated renewal. Either way renewal is recurring — most outages trace to automation that silently stopped, which is why the days-left number here goes amber at 14.
Does a wildcard certificate cover everything?
One level only. *.example.com covers app.example.com and www.example.com, but not example.com itself (unless listed separately, which it usually is) and not a.b.example.com. Multi-level coverage needs the deeper name in the SAN list explicitly.
What is the SAN list?
Subject Alternative Names — the actual list of hostnames a certificate covers. Browsers match against SANs, not the display name. If the name you serve isn't in that list, the certificate doesn't cover it, whatever the Common Name suggests.
Can this check an expired or self-signed certificate?
Yes — that's much of the point. The inspection handshake accepts any certificate so you can see the details of exactly the certificates browsers hide behind warning pages. A separate verification pass then reports whether a normal client would trust it.
Why can't I check port 8080 or other ports?
The checker allows 443 and 8443 — the standard HTTPS ports. Arbitrary ports would turn a certificate checker into a generic port prober of other people's servers, which is not something a public tool should be.