Skip to main content

SSL Certificate Checker

Inspect the live TLS certificate a domain serves: when it expires, who issued it, and exactly which hostnames it covers.

Enter the domain whose certificate you want to inspect — example.com.

This tool queries an external service to answer your request. Only the value you enter — such as a domain or IP address — is sent. Your other data stays on your device.

This tool reads public records — DNS, WHOIS and certificate data that registries and servers publish openly. It sends nothing to the host you enter and changes nothing there. Use it on infrastructure you own or are authorised to look into.

About the SSL Certificate Checker

Fetch the certificate a domain is actually serving right now and read what it says: when it expires, who issued it, how it is signed, and which hostnames it covers. This is the live certificate from the live host, not a record of one that was installed some time ago.

Two problems account for nearly every certificate error a visitor ever sees, and both are visible here before anyone else notices them. The first is expiry. Certificates are short-lived now — ninety days is standard, and the industry is moving shorter — so renewal is automated, and automation fails quietly. Nothing warns you that a renewal cron stopped working three months ago; the site simply starts showing a full-page browser warning one morning. The expiry banner here is deliberately loud below thirty days, because thirty days is the point at which Let's Encrypt would normally have renewed already, and a certificate still sitting at twenty-nine days means something has stopped.

The second is coverage, and it is the one people find hardest to diagnose. A certificate is valid only for the names listed inside it, and a certificate issued for example.com does not cover www.example.com unless that name is listed too. The result of getting this wrong is a browser error that says the connection is not private on one URL while the other works perfectly — which reads like a mystery and is simply a missing entry. Every hostname the certificate covers is listed here, so you can check the one you are serving is genuinely among them. A wildcard such as *.example.com covers one level of subdomain and no more: it matches shop.example.com but not eu.shop.example.com.

The full chain is shown as well, because an incomplete chain is the third classic failure. A server that sends its own certificate but omits the intermediate above it will work perfectly in most desktop browsers, which cache intermediates, and fail on mobile devices and command-line clients that do not — producing a bug report that nobody can reproduce.

How to use the SSL Certificate Checker

  1. Enter the domain

    Type the hostname you want to check — example.com, or www.example.com if that is the name you serve. They can have different certificates.

  2. Run the check

    Complete the verification check and press Check certificate. The certificate is fetched from the live host at that moment.

  3. Read the expiry banner

    It is green well ahead of time, amber inside thirty days, and red inside seven or once expired. Amber usually means automatic renewal has stopped rather than that renewal is not configured.

  4. Check the covered names

    Confirm the exact hostname you serve appears in the covered list. A certificate for example.com does not cover www.example.com unless that name is listed too.

Frequently asked questions

My certificate is valid but the browser still shows a warning. Why?

Most often because the name you are visiting is not covered by the certificate. Check the covered hostnames list here against the exact address in the browser bar — a certificate issued for example.com genuinely does not cover www.example.com. The next most common cause is an incomplete chain: your server sends its own certificate but not the intermediate above it, which works in desktop browsers that have the intermediate cached and fails everywhere else.

What does a wildcard certificate actually cover?

Exactly one level of subdomain. A certificate for *.example.com covers shop.example.com and mail.example.com, but not eu.shop.example.com, which is two levels down, and not the bare example.com itself unless that is listed separately. Most wildcard certificates list the bare domain as well for this reason, and you can see whether yours does in the covered names list.

How long before expiry should I worry?

If you use automatic renewal, worry at thirty days. Let's Encrypt and most ACME clients renew when a third of the ninety-day life remains, so a certificate still showing twenty-nine days has already missed at least one renewal attempt and something is broken. If you renew by hand, thirty days is a comfortable window to act in and seven is an emergency.

Does this check whether my TLS configuration is secure?

No, and it is worth being clear about the difference. This reads the certificate — its dates, its issuer, its key and the names it covers. It does not test which TLS versions or cipher suites your server will negotiate, which is a separate question about server configuration rather than about the certificate. For that you want a dedicated TLS configuration scanner.

Why does the certificate differ from what I installed?

Usually because something in front of your server is terminating TLS. A CDN, a load balancer or a reverse proxy will present its own certificate rather than yours, and that is normal — it is what you are asking a CDN to do. What you see here is what a visitor sees, which is the thing that actually matters. If it is not what you expected, the certificate you installed is probably on a machine that no longer faces the public.

Do you store the domains I check?

No. The domain is sent to the lookup service to fetch the certificate and is not written to our database or our logs. We count that a certificate check happened, with no record of which domain, who asked, or what was returned.