SSL Certificate Checker

We open a real TLS handshake to the host on port 443, fetch the certificate chain it presents, and validate it against Node’s root trust store. We report the protocol version, cipher, expiry date, hostname match, key strength, signature algorithm, and the full chain.

SSL/TLS Certificates: What They Are and Why Every Website Needs One

When you visit a website and see a padlock icon in the address bar, that means the connection is protected by an SSL/TLS certificate. SSL (Secure Sockets Layer) is the older name; today almost everything uses its successor, TLS (Transport Layer Security). Together they encrypt the data travelling between your browser and the server so passwords, payment details, and personal information cannot easily be read by anyone in between.

Most TLS audits are mountains of detail when, for production sites, the key questions are simple: does the certificate match the hostname, is it issued by a CA the browser trusts, is it within its validity window, is the key strong enough, and is the negotiated protocol modern? This tool answers each one and shows you the chain it inspected.

You do not need to be a security engineer to use it. Enter any domain above and we open a real TLS handshake on port 443 — the same connection your browser makes when you visit https://example.com. The sections below explain what the results mean in everyday language.

What Is HTTPS and How Does It Relate to SSL?

HTTPS is simply HTTP (normal web traffic) wrapped inside a TLS-encrypted tunnel. The “S” stands for secure. Modern browsers mark non-HTTPS sites as “Not Secure,” which erodes visitor trust even on pages that do not collect sensitive data.

Google has treated HTTPS as a lightweight ranking signal since 2014. More importantly, browsers now restrict powerful features — geolocation, camera access, service workers — to secure contexts only. If you run a website in 2026 without a valid certificate, you are fighting both users and search engines.

How This SSL Checker Works

We open a real TLS handshake to the host on port 443, fetch the certificate chain it presents, and validate it against a trusted root store. We report the protocol version, cipher, expiry date, hostname match, key strength, signature algorithm, and the full chain — the same details a browser checks before showing you the padlock.

Unlike a simple “is the site up?” ping, this tool inspects the actual cryptographic credentials the server offers. That matters because a site can respond on port 443 with an expired certificate, a certificate issued for a different domain, or a self-signed cert that no browser trusts. Each of those scenarios looks like HTTPS at a glance but fails the security check.

Reading Your Results: A Plain-English Walkthrough

After you run a check, the results are grouped into sections. Here is what each part tells a normal user:

  • Subject & Issuer — who the certificate was issued to (your domain or organisation) and who signed it. Trusted issuers include Let's Encrypt, DigiCert, Sectigo, and Google Trust Services.
  • Common Name (CN) — the primary hostname on older certificates. Modern browsers rely more on Subject Alternative Names.
  • Valid From / Valid To— the certificate's active window. Expired certificates trigger browser warnings immediately.
  • Days until expiry — how long before renewal is required. Do not wait until day zero.
  • Trusted— whether the certificate chains back to a root authority your system recognises. “No” usually means self-signed, misconfigured chain, or unknown issuer.
  • Key & Signature Algorithm — the cryptographic strength. RSA 2048-bit or ECDSA P-256 are common modern standards.
  • Subject Alternative Names (SANs) — every hostname covered by one certificate, includingwww variants and subdomains.
  • Certificate chain— the path from your site's cert up through intermediate CAs to a trusted root. A broken chain causes trust errors even when the leaf certificate is valid.
  • Findings — a plain summary of issues, warnings, and passes so you do not have to interpret raw TLS data yourself.

Protocol Versions: TLS 1.3, TLS 1.2, and What to Avoid

TLS 1.3 (finalised in 2018) is the gold standard — fewer round trips, only modern ciphers, and improved security against known attacks. TLS 1.2 is still widely used and acceptable for most sites. Anything older — TLS 1.0, TLS 1.1, or SSL 3.0 — should be disabled. If your server negotiates those legacy protocols, you have a backwards-compatibility problem that attackers can exploit.

Our tool reports the protocol version negotiated during the handshake. Seeing TLSv1.3 is ideal. Seeing only TLSv1.2 is fine for now but worth monitoring as standards evolve. If you manage the server, Mozilla's SSL Configuration Generator is the industry-standard reference for hardening settings.

Hostname Matching and Wildcard Certificates

Modern browsers ignore the certificate's Common Name and check the Subject Alternative Names instead. We list every DNS name on the SAN list and explicitly verify the requested host matches one of them, including wildcard rules.

A wildcard certificate for *.example.com covers subdomains like blog.example.combut not the bare domain example.comunless it is listed separately. A common mistake after launching a new subdomain is forgetting to add it to the certificate — visitors see a scary “Your connection is not private” warning even though the main site works fine.

Certificate Authorities and Let's Encrypt

A Certificate Authority (CA) is a trusted organisation that verifies domain ownership and issues signed certificates. Browsers ship with a list of trusted root CAs; if your certificate is not signed by one of them, users see an error page.

Let's Encrypt revolutionised the web by offering free, automated certificates. Most shared hosts and control panels (cPanel, Plesk, Cloudflare) integrate it with one click. Paid CAs still dominate enterprise environments where extended validation (EV) or organisation-validated (OV) certificates are required for compliance or brand display.

Renewal Cadence: Do Not Let Certificates Expire

Most public CAs now issue certificates valid for 90 days (Let's Encrypt) or up to roughly 13 months (commercial CAs, following browser-imposed limits). Shorter lifetimes reduce the damage from compromised keys but mean renewal must be automated.

Set up automatic renewal through your host, CDN, or a tool like Certbot, and monitor expiry dates from outside the system that owns them. An expired certificate does not just look bad — it stops transactions, breaks API integrations, and can take hours to fix if you discover it on a Friday evening.

Common SSL Problems and What They Mean

  • Certificate expired — the validity window ended. Renew immediately; browsers will block all visitors until you do.
  • Hostname mismatch — you visited www.example.com but the cert only coversexample.com (or vice versa). Add the missing name to SANs or redirect consistently.
  • Untrusted / self-signed — the certificate was not issued by a recognised CA. Fine for internal testing; never acceptable for public websites.
  • Incomplete chain — the server forgot to send intermediate certificates. Some browsers guess the chain; others fail. Install the full chain from your CA.
  • Weak key or signature — RSA keys below 2048 bits or SHA-1 signatures are deprecated. Re-issue with modern algorithms.
  • Mixed content — the page loads over HTTPS but pulls images or scripts over HTTP. Browsers may block those assets and show warnings.

Everyday Reasons to Check SSL Certificates

  • Before launching a new site — confirm HTTPS works on both www and non-www versions before sharing the URL publicly.
  • After changing hosts or CDNs — migrations often leave certificates misconfigured or pointing at the old provider.
  • Monitoring expiry — schedule monthly checks on production domains so you catch 30-day warnings early.
  • Auditing client sites — agencies and freelancers can verify SSL health without logging into every hosting panel.
  • Checking suspicious sites — phishing pages sometimes use valid HTTPS to appear legitimate. A certificate alone does not prove trustworthiness, but an invalid one is a clear red flag.
  • SEO and Core Web Vitals audits — HTTPS is a baseline requirement, not an optional enhancement.

What This Tool Cannot Tell You

This checker validates the certificate presented during a single TLS handshake from our server. It does not scan your entire site for mixed content, test every subdomain, or audit server-side cipher configuration beyond what was negotiated. It also cannot detect vulnerabilities like Heartbleed or misconfigured HSTS headers — those require dedicated security scanners.

A valid certificate proves the connection is encrypted and the domain was verified at issuance time. It does not guarantee the site is honest, malware-free, or well-maintained. Always combine SSL checks with common sense when evaluating unfamiliar websites.

Helpful Resources to Learn More

These trusted guides explain SSL/TLS concepts in more depth. All links open in a new tab.

Try It Now

The best way to understand SSL is to inspect a real certificate. Enter your own domain above and check the expiry date, SAN list, and trust status. Then try a major site you use daily and compare. If anything shows a warning or fail finding, address it before your visitors or search engines do. No sign-up, no install — just type a domain and check.