SSL Checker

Enter a domain and this tool opens a live TLS connection to the server, reads the certificate it actually presents, and reports everything that matters: is it valid right now, when it expires, who issued it, whether it covers the hostname, whether the chain is complete, which names (SANs) it protects, the key type and signature algorithm, and which TLS versions the server accepts. It is the fast way to answer "is HTTPS set up correctly on this site?"

How to use the SSL Checker

Type any domain name — example.com, www.example.com, or a host on a non-standard HTTPS port (example.com:8443 works too if you include the port) — and press Check SSL. In about a second you get a full report card:

• Status badges at the top tell you instantly whether the certificate is expired, whether it matches the hostname you entered, whether it is self-signed, and whether the chain is complete.
• Certificate details — common name, issuing CA, the exact valid-from and valid-until dates with days remaining, the public-key type and size (RSA 2048, EC 256, etc.), the signature algorithm, serial number and SHA-256 fingerprint.
• Covered names — every Subject Alternative Name on the certificate, so you can confirm it protects all the hostnames you serve.
• Certificate chain — each certificate the server sent, from the leaf up through the intermediate CA(s), with a verdict on whether the chain is complete.
• TLS protocol support — whether the server still accepts deprecated TLS 1.0/1.1 or only modern TLS 1.2/1.3.

You can also link straight to a result: ?host=example.com on this page's URL pre-fills and runs the check automatically, which is handy for bookmarks or sharing.

What an SSL certificate check tells you

An "SSL certificate" (more precisely a TLS certificate) is the credential a website presents to prove its identity and to set up the encrypted HTTPS connection your browser shows with a padlock. When a browser connects, it verifies four things, and this checker reports each one:

• Validity period — every certificate has a not-before and not-after date. An expired certificate causes a full-page browser warning ("Your connection is not private"), which blocks visitors and tanks conversions. This is the single most common HTTPS outage, and the easiest to prevent by watching the expiry date.
• Hostname match — the certificate must list the exact hostname the visitor is using, either as the Common Name or, in practice today, in the Subject Alternative Name list. A mismatch (for example a certificate for example.com served on www.example.com) also triggers a hard browser error.
• Trust chain — browsers only trust certificates that chain up to a root CA in their trust store. The server must send the leaf certificate plus any intermediate certificates so the browser can build that path. A missing intermediate is the classic "works in my browser but fails on Android" bug, because some clients cannot fetch the missing link themselves.
• Cryptographic strength — the key type and size (RSA 2048-bit, ECDSA P-256), the signature algorithm (SHA-256 and above; SHA-1 is long dead), and the TLS protocol version all affect how secure and how fast the connection is.

Because the check happens over a real connection to the live server, it reflects exactly what a visitor's browser sees right now — not what a cached scan or a control-panel field claims. That makes it the right tool for confirming a freshly issued certificate has deployed, diagnosing a certificate error a user reported, or spot-checking a site before launch.

Common use cases

• After installing or renewing a certificate — confirm the new certificate is live, the dates are right, and the chain is complete before you tell anyone it is done.
• Debugging a "not secure" warning — the badges immediately separate the three common causes: expired, hostname mismatch, or untrusted/incomplete chain.
• Monitoring expiry — drop in your domains periodically (or bookmark ?host=yourdomain.com) so a certificate never lapses unnoticed.
• Vendor and third-party audits — verify that an API endpoint, payment gateway or partner site you depend on has a healthy certificate and modern TLS.
• Pre-launch QA — check a staging or about-to-go-live host for the right hostnames in the SAN list and a complete chain.
• Security review — flag servers still accepting deprecated TLS 1.0/1.1 or using weak keys, which fail PCI DSS and most security baselines.

How to fix the most common SSL errors

• Certificate expired — reissue/renew from your CA or enable auto-renewal (Let's Encrypt with certbot or your host's panel). Certificates can be renewed up to ~90 days early without losing remaining validity.
• Name mismatch — issue a certificate that includes every hostname you serve (apex and www, plus any subdomains) in the SAN list, or use a wildcard *.example.com. Then make sure your server presents that certificate for the right virtual host.
• Incomplete chain — install the "fullchain" file (leaf + intermediates), not just the leaf certificate. With Let's Encrypt that is fullchain.pem; with a commercial CA, concatenate the leaf and the provided CA-bundle.
• Self-signed in production — replace it with a certificate from a public CA. Self-signed certificates are fine for local development but always error for real visitors.
• Deprecated TLS — disable TLS 1.0 and 1.1 in your web server or load balancer and keep only TLS 1.2 and 1.3.