SSL/TLS Checker

What is the SSL/TLS Checker?

The SSL/TLS Checker is a free tool that connects to a website on port 443 and inspects the certificate it presents. It reports whether the certificate is trusted and in date, how many days remain, whether it covers the hostname, the TLS version and cipher negotiated, and which security headers the site sends, with a score out of 100.

How to use the SSL/TLS Checker

1. Enter the domain, such as example.com or shop.example.com. The check covers the hostname you type.
2. Press Check SSL.
3. Read the certificate card: who it was issued to and by, the valid-from and expiry dates, days left, the cipher and the hostnames it covers.
4. Check the security score and the risk assessment, which lists each issue found: an untrusted certificate, a hostname it does not cover, an old TLS version, expiry within 30 days or a missing security header.
5. Scroll to the security headers, the server's IP address and the TLS protocol it negotiated.

How do I check if an SSL certificate is valid?

An SSL certificate is valid when three things are true: it is in date, it chains to a trusted root, and the hostname appears in its Subject Alternative Name (SAN) list. They are separate checks, and a certificate can pass two and fail the third.

The hostname check is the one people miss. A certificate from a real CA, correctly signed and in date, still triggers a browser error if it covers example.com and the visitor asked for shop.example.com. Browsers match the hostname against SAN entries, not the Common Name, and this checker does the same.

Does a wildcard SSL certificate cover the root domain?

No. *.example.com covers www.example.com and shop.example.com, but not example.com itself and not api.v2.example.com. A wildcard stands in for exactly one label.

If the bare domain needs HTTPS, it has to be listed as its own SAN entry. When a renewed wildcard certificate breaks only the root domain, this is almost always why.

Why is my SSL certificate not trusted?

An SSL certificate is usually not trusted because it has expired, it does not cover the hostname, or the server sends it without its intermediate certificate. The first two show up everywhere. The third is intermittent.

When the intermediate is missing, some browsers still connect because they already have it cached or fetch it themselves, while fresh devices, command-line tools and webhooks fail. This checker validates the chain the server actually sends, so a missing intermediate shows up here as an untrusted certificate. If HTTPS works on your laptop and fails in one integration, check the chain first.