SSL Certificate Checker
Read the certificate a site actually presents — including the broken ones your browser refuses to show you.
Why you need a tool for this at all
Your browser already checks certificates, and it is better at it than any web page could be. What it will not do is show you a broken one. When validation fails you get an interstitial and a vague reason; the certificate itself is behind two more clicks, if it is reachable at all. And the failures worth diagnosing are usually the ones where your browser is perfectly happy and somebody else’s is not.
So the check above runs on a server, deliberately without trusting what it finds, and reports what the host actually presented. Expired, self-signed, issued for a different name — all of it comes back as data rather than as a wall.
The four failures, in the order you will meet them
Expired
The most common and the most avoidable. Every browser shows a full-page warning, and the site is effectively down for anyone unwilling to click through. It happens because someone renewed manually, once, three hundred and ninety-eight days ago, and then left the company.
Hostname mismatch
The certificate is genuine and current but does not cover the name you used. Nearly always the wildcard rule: *.example.com does not cover example.com. Both names have to be on the certificate, and this checker lists every name it found so you can see at a glance which one is missing.
Incomplete chain
The one that produces the strangest bug reports. The server sends its own certificate but omits the intermediate that links it to a trusted root. Desktop browsers usually fetch the missing piece themselves and say nothing. Mobile browsers, Java clients, older Android, curl and most API consumers do not, and simply fail.
The result is a site that works perfectly on the developer’s laptop and intermittently for everyone else, which is why the chain section above lists exactly what the server sent rather than what could be reconstructed.
Self-signed
Issued by itself, so no client trusts it by default. Entirely reasonable on an internal service where you distribute the certificate yourself, and never usable on the public web.
What the padlock does and does not mean
A valid certificate establishes two things: that you are talking to whoever controls that domain name, and that the traffic between you cannot be read or modified in transit. That is genuinely valuable and it is the entire guarantee.
What it does not establish is that the operator is honest. Certificates are free and issued in seconds, so phishing sites have valid ones as a matter of course. The padlock has never meant “this site is safe”, which is why browsers have spent the last few years quietly removing it as a positive indicator and now mark only the absence of encryption.
Everything on your certificate is public
Worth knowing before you add hostnames to one. Since 2018 every publicly trusted certificate must be submitted to Certificate Transparency — append-only public logs that browsers check and refuse certificates missing from.
The security benefit is real: a certificate authority cannot quietly issue a certificate for your domain to someone else without it appearing in a log you can watch. The side effect is that every name on every certificate is searchable. Putting staging-admin.example.com on a public certificate publishes the existence of that host to anyone who cares to look, and people do look — log monitoring is a standard reconnaissance step.
Renewal is about to stop being optional
The maximum lifetime of a public certificate has been falling for years: five years, then three, then two, and 398 days since 2020. The CA/Browser Forum has now agreed a schedule that takes it to 200 days in 2026, 100 in 2027, and 47 by 2029.
At 47 days, renewing by hand means doing it eight times a year on every host, and the failure mode is your site going down. Automation via ACME — Let’s Encrypt, or whatever your hosting provider offers — stops being good practice and becomes the only workable option. If you are checking a certificate here because you got an expiry email, that is the underlying thing to fix.
What this does not check
Deliberately narrow. It reads the certificate and the negotiated connection, and stops there. It does not fetch the page, grade your cipher suites, test for protocol vulnerabilities, or score your configuration out of a hundred. For a full server-configuration audit, Qualys SSL Labs is the established tool and does it thoroughly.
For the adjacent questions: the DNS leak test covers which resolver is answering for you, and the IP lookup covers what a given address belongs to.
Certificate questions that come up
The site works in my browser but this says the certificate is not trusted. Who is right?
Both, and the usual explanation is an incomplete chain. A server is supposed to send its own certificate plus the intermediates that link it to a trusted root. If it sends only its own, desktop browsers frequently paper over the gap by fetching the missing intermediate themselves — a feature called AIA fetching. Many mobile browsers, API clients, Java applications and command-line tools do not. So the site works for you and fails for a subset of your users, which is exactly the bug that gets reported as "it only breaks for some people". This checker reports what the server actually sent.
Why is my certificate valid for www.example.com but not example.com?
Because a wildcard covers exactly one label, and only the leftmost one. *.example.com matches www.example.com and api.example.com, but it does not match example.com itself, nor a.b.example.com. The bare domain has to be listed separately in the subject alternative names. It is one of the most common certificate mistakes, and it produces a site that works with the www prefix and fails without it.
How long should a certificate last?
Public certificates are capped at 398 days today, and the industry is moving decisively shorter — the CA/Browser Forum has agreed a schedule that brings the maximum down to 47 days by 2029. The practical consequence is that manual renewal stops being viable. If yours is not renewing automatically via ACME or your hosting provider, that is worth fixing before the deadline does it for you.
What is the difference between SSL and TLS?
TLS is the protocol; SSL is its predecessor, and the last version of it was deprecated in 2015. Everything running today is TLS. The word "SSL" survives in the names of products, certificates and job titles purely out of habit, which is why this page is called an SSL checker while every value it reports is TLS. If a server genuinely offers SSL 3.0, that is a finding in itself.
Does a valid certificate mean the site is safe?
No, and conflating the two is the single most common misunderstanding about certificates. A certificate proves that you are talking to whoever controls that domain name, and that nobody in between can read or alter the conversation. It says nothing about whether that person is honest. Phishing sites have valid certificates as a matter of routine — they are free and issued in seconds. The padlock means encrypted, not trustworthy.
Can I see every certificate issued for my domain?
Yes, and it is worth doing. Every publicly trusted certificate must be logged to Certificate Transparency, a set of append-only public logs that browsers check. Search crt.sh for your domain and you will see every certificate ever issued for it — which is how you discover one you did not ask for. It also means the subject alternative names on your certificates are public, so putting a private internal hostname on a public certificate publishes that hostname.
A certificate protects the connection between a visitor and one site. It does nothing about what the networks in between can see about which sites you visit at all — that metadata is visible even when every connection is encrypted. What your network can still see
Last reviewed . Found something out of date? Tell us.