SSL check
SSL Checker
Open a real TLS connection to any site and read the certificate it presents — who issued it, when it expires, whether it covers the hostname, and whether browsers will trust it.
What This Tool Does
This tool connects to the host on port 443 exactly as a browser would, completes a TLS handshake, and reads the certificate chain the server sends back. Nothing is looked up in a third-party certificate database, so what you see is what a visitor would get if they loaded the site at this moment.
Five things are checked independently, because “is my SSL working” collapses several unrelated failures into one question. A certificate can be perfectly valid and still be rejected for the wrong hostname. It can be trusted by your desktop browser and rejected by every phone. It can be years from expiry and sit behind an intermediate that expires next month.
Because the check runs against a certificate that may be broken, the connection is made without aborting on verification failure. That is the only way to report why a bad certificate is bad rather than simply refusing to look at it.
How to Read Your Results
Browser trust
The headline result: does the chain verify against the public root store? This is the same question a browser asks, and a failure here means visitors see a full-page interstitial warning before any of your content loads. The specific failure code is shown alongside it, because the fix for an expired certificate has nothing in common with the fix for a missing intermediate.
Expiry
Days remaining until the certificate’s notAfter date. Under 30 days is flagged as a warning, because 30 days is when Let’s Encrypt starts attempting renewal. If you have automation and this number is below 30, the meaningful finding is not “renew soon” — it is that renewal has already failed at least once.
Hostname match
Whether the certificate actually covers the name you typed, matched under RFC 6125 including wildcard rules. The classic failure is a certificate covering example.com but not www.example.com, or the reverse.
Wildcards are narrower than people expect: *.example.com matches shop.example.com but not eu.shop.example.com, and not the bare example.com either. A wildcard covers exactly one label.
Certificate chain
How many certificates the server presented, and whether they link up correctly. A server should send its own certificate plus every intermediate, but not the root — the browser already has the root.
This section also flags an intermediate that expires before your own certificate does. When that happens the site breaks on the earlier date, and renewing your certificate alone will not prevent it.
TLS version
The protocol version actually negotiated. TLS 1.3 is current and TLS 1.2 is accepted everywhere. TLS 1.0 and 1.1 were formally deprecated by RFC 8996 in 2021 and are refused by every current browser, so seeing them here means the site is already broken for most visitors.
Common Problems and Fixes
The certificate has expired
Visitors see a security warning and most will leave. Renew it — but if you use automated issuance, find out why renewal stopped rather than just reissuing by hand. Expiry with automation in place means the renewal job has been failing silently for a month, and it will fail again in ninety days. Check that the renewal timer is running and that the HTTP validation path is still reachable.
Only one certificate was presented
The server is not sending its intermediates. Reinstall using the full chain file your authority supplied — commonly fullchain.pem, or a file described as a bundle — rather than the certificate on its own. This is the single most common cause of “works for me, broken for everyone else”.
The certificate does not cover this hostname
Reissue it with every hostname you actually serve listed, including the www variant if you use one. If you only ever intended to serve one of them, redirect the other at the HTTP layer instead — but note that the redirect itself happens after the TLS handshake, so the certificate still has to be valid for the name being redirected away from.
The certificate is self-signed
Nothing vouches for it, so no browser will trust it. This is fine on a staging box you control and never acceptable in production. Replace it with a certificate from a publicly trusted authority; Let’s Encrypt issues them free and renews them automatically.
An intermediate expires before the certificate
Your certificate authority has almost certainly published a newer intermediate. Update the chain file on the server. Renewing the site certificate through your usual process often picks up the new intermediate automatically, but confirm it here afterwards rather than assuming.
No HTTPS at all
Nothing is listening on port 443. If the site is meant to be reachable over HTTPS, check that the web server is configured for it and that a firewall is not blocking the port. Every mainstream host offers free automated certificates now, so there is no cost reason to serve a site over plain HTTP.
What This Tool Cannot Tell You
- It does not check for mixed content. A perfect certificate still produces a “Not secure” warning if the page loads assets over plain HTTP. That is a property of the page, not the connection.
- It does not check revocation. A certificate revoked by its issuer will still appear valid here. OCSP and CRL checking is a separate question, and browsers themselves are inconsistent about it.
- It checks port 443 only. Certificates on mail ports or application ports are not inspected.
- It tests one IP address. If the hostname resolves to several servers, only the first is checked — so a single misconfigured server in a pool can be missed. The address actually tested is printed in the transcript.
- It does not grade cipher suites. The negotiated protocol and cipher are reported, but a full cryptographic audit is a different tool.
Frequently Asked Questions
What is an SSL checker?
It opens a TLS connection to a site the way a browser does and reads the certificate the server actually presents, then reports whether a browser would accept it.
This one checks five things independently: whether the chain verifies against the public root store, how long until the certificate expires, whether it covers the hostname you asked about, whether the server sent the full chain, and which TLS version was negotiated.
My certificate is valid, so why does my browser say “Not secure”?
Almost always one of three things, and this tool distinguishes them. The certificate may not cover the exact hostname — a certificate for example.com does not automatically cover www.example.com. The server may be sending an incomplete chain. Or the page may be loading images, scripts or stylesheets over plain HTTP, which browsers call mixed content.
Mixed content is the one case this tool cannot see, because it inspects the connection rather than the page. If all five checks here pass and the browser still complains, open the browser console — it names the offending resources directly.
What is a certificate chain, and why would it be incomplete?
Your certificate is signed by an intermediate certificate, which is signed by a root certificate that browsers already trust. The server has to send its own certificate and every intermediate, so the browser can follow the links up to a root it recognises.
Chains break when someone installs only the certificate file rather than the bundle. The tell-tale symptom is that it works in one place and fails in another: desktop browsers often cache intermediates from previous sites or fetch the missing one automatically, so the site looks fine to the person who set it up while failing for mobile users and for command-line clients.
It works in my browser but fails on my phone or in curl. Why?
That pattern is a missing intermediate almost every time. Desktop browsers can paper over it; older Android versions, curl, and most programming-language HTTP clients cannot.
Check the Certificate chain result above. If it reports that only one certificate was presented, install the full chain file — usually named fullchain.pem or something ending in bundle — instead of the certificate on its own.
How long before expiry should I renew?
If renewal is automated, it should already have happened by 30 days out — that is when Let's Encrypt begins trying. A certificate inside 30 days with automation configured does not mean you should renew manually; it means the automation is failing and will keep failing.
If you renew by hand, treat 30 days as the point to act. Certificates expire at a fixed instant, not at the end of a business day, and they routinely expire at inconvenient hours.
What is the difference between SSL and TLS?
TLS is the protocol in use today; SSL is its predecessor and every version of it has been insecure and disabled for years. The name stuck, so “SSL certificate” is still what everyone says, including certificate authorities selling them.
The certificate itself is not really SSL or TLS specific — it is an X.509 certificate used by whichever protocol negotiates the connection. The TLS version result above reports what was actually negotiated.
Does a more expensive certificate provide stronger encryption?
No. The encryption strength comes from the TLS version and cipher negotiated between browser and server, not from the price of the certificate. A free Let's Encrypt certificate and an expensive extended-validation one produce an identical connection.
What you pay for is the level of identity checking the authority performed, plus warranties and support. Since browsers stopped displaying the green company name in the address bar, most visitors cannot tell the difference at all.
Why does this only check port 443?
Because that is the port browsers use for HTTPS, and this tool answers the question “would a visitor's browser trust this site”. Certificates on other ports — mail on 465 or 993, or an application server on 8443 — are not checked.
For those, openssl s_client with an explicit port is the right tool. The command is printed above the certificate transcript and you can change the port in it.