Skip to main content

SSL Certificate Checker

What it does

The SSL Certificate Checker connects to a host on the configured port (443 by default), captures the TLS certificate served, and reports the cert metadata: subject (who the cert is for), issuer (who issued it), expiry date, subject alternative names (other hostnames the cert covers), signature algorithm, and TLS handshake time. Expiry is colour-coded: under 14 days is critical, under 30 is a warning.

Common situations

A site renewed its SSL certificate but you want to confirm the new cert is actually being served and is valid. Check the host; the issuer, expiry, and SANs should match the new cert.

You are migrating from one CDN to another and want to verify the new CDN is presenting your domain’s cert correctly. Check during the cutover; if the SSL info is wrong, browsers will show certificate errors.

A subdomain stopped working and users are reporting “this connection isn’t secure” warnings. Check the cert on the affected subdomain. The cause is usually a missing SAN (the cert covers the parent domain but not the subdomain) or an expired cert.

You are auditing a competitor’s stack to understand their CDN and infrastructure choices. The cert issuer (“Let’s Encrypt”, “Cloudflare”, “DigiCert”, etc.) reveals their CDN or hosting layer; the SAN list reveals the subdomain structure.

A monitoring alert reports the cert is expiring in 12 days. Verify the expiry date directly; if accurate, expedite the renewal. Most modern hosting auto-renews 30+ days before expiry, but the auto-renewal can fail silently.

What you need to know

An SSL/TLS certificate is the cryptographic credential that proves a domain owns the encryption keys it’s using. Browsers verify the cert chain on every HTTPS connection. A missing, expired, or invalid cert produces the “this connection is not secure” warning that scares users off.

What the checker reports:

Subject: who the cert is for. Includes the Common Name (typically the primary domain) and other identifying fields. For most modern certs, the Subject CN is just the domain (example.com).

Issuer: who issued the cert. The major Certificate Authorities are Let’s Encrypt (free, auto-renewed), DigiCert, Sectigo (formerly Comodo), GlobalSign, GoDaddy, and Cloudflare (for sites behind Cloudflare). Issuer affects trust; every modern browser trusts the major CAs.

Validity period: when the cert is valid. Modern certs are issued for 1 year maximum (90 days for Let’s Encrypt). Expiry has been shortening over time. The industry is moving toward 47-day cert lifetimes by 2027. Auto-renewal is essential.

Subject Alternative Names (SANs): the list of hostnames the cert covers. A cert for example.com typically also covers www.example.com via SANs. Wildcard certs cover *.example.com (any direct subdomain). Most multi-host setups need explicit SANs for each hostname.

Signature algorithm: how the cert is signed. SHA-256 with RSA is the modern standard. Anything older (SHA-1) is deprecated and should never appear in production certs. Newer ECDSA-based signatures are also fine.

Handshake time: the time taken to complete the TLS handshake. Sub-100ms is good; over 200ms suggests the host is far from our infrastructure or has a slow TLS implementation. TLS 1.3 reduces handshake to 1-RTT instead of 2-RTT, which matters for first-paint performance.

The expiry warnings are calibrated:

  • Under 14 days: critical. Renewal must happen now.
  • 15-30 days: warning. Auto-renewal should have triggered by now; if it hasn’t, investigate.
  • Over 30 days: OK.
  • Expired: HTTPS already broken.

What the checker does NOT do: validate the full cert chain (some intermediate CA certs may be missing on the server even if the leaf cert is present), check OCSP stapling, or test specific cipher suites. For deep TLS inspection, SSL Labs’ Server Test is the canonical tool.

Frequently asked questions

What’s the difference between SSL and TLS?

SSL is the older protocol; TLS is the modern one. People still say “SSL certificate” out of habit, but every modern certificate is actually a TLS certificate. The two terms are used interchangeably in casual usage.

How long should an SSL cert last?

Maximum 1 year for paid certs, 90 days for Let’s Encrypt. The CA/Browser Forum is moving toward 47-day max lifetimes by 2027, which makes manual renewal impractical and forces auto-renewal.

What happens when a cert expires?

Browsers show a security warning that blocks navigation. Users see “Your connection isn’t private” or similar. Most users abandon the site. Search bots also fail to crawl over expired HTTPS. A few hours of expired cert can crater a site.

Does the cert need to cover both example.com and www.example.com?

Yes. If users hit either form, the cert must cover that hostname. Most certs include both via SANs. Wildcard certs (*.example.com) cover any direct subdomain but not the bare domain. Wildcard certs must include the bare domain as an additional SAN.

What’s a wildcard certificate?

A cert that covers any subdomain at one level. *.example.com matches www.example.com, blog.example.com, api.example.com, but not app.dev.example.com (two levels deep).

Should I worry about the signature algorithm?

If it’s SHA-256 with RSA or any ECDSA variant, you’re fine. SHA-1 has been deprecated since 2017 and shouldn’t appear in any production cert. If you see SHA-1, rotate immediately. Modern browsers reject SHA-1 certs.

Is Let’s Encrypt as trustworthy as paid certs?

For encryption strength, identical. The difference is identity validation: Let’s Encrypt does Domain Validation only (proves you control the domain). Extended Validation (EV) certs from major CAs do organisation validation (verifies you are who you claim to be). EV certs no longer get the green address bar in browsers, so the marketing benefit is mostly gone. Domain Validation is sufficient for most sites.

What’s OCSP stapling?

A mechanism where the server proactively delivers the cert revocation status to clients, removing the need for the client to query the CA. Improves both performance and privacy. Most modern web servers support it; the checker doesn’t currently report whether OCSP stapling is enabled.

Common problems

Problem: Cert is valid but browser still shows “not secure” warning.

Usually a missing intermediate cert in the chain. The leaf cert is fine but the server isn’t including the intermediate CA cert that links it to the trusted root. Check with SSL Labs. Incomplete chains are a common server config mistake.

Problem: Subdomain shows different cert than parent domain.

Either the subdomain has its own cert (common with multi-region CDNs) or it’s not in the parent’s SAN list (causing browsers to reject). Check the subdomain’s cert directly. If the issuer differs from the parent, the subdomain has its own cert; if the cert doesn’t include the subdomain in SANs, it’s misconfigured.

Problem: Auto-renewal failed and cert is about to expire.

Common causes: domain validation failure (DNS changed and ACME challenge can’t validate), rate limiting at Let’s Encrypt, or a misconfigured renewal script. Check the renewal logs. Most ACME clients log failure reasons clearly. Manual renewal is the immediate fix; figuring out why auto failed is the longer-term work.

Problem: Cert reports as expired but the host is serving fine.

Check the system clock on the host. If it’s wrong, cert validation succeeds against the wrong reference. Also check whether the test is hitting the right server (DNS might be pointing elsewhere). Browsers usually catch this; if browsers are happy but the checker reports expired, something is unusual.

Problem: Cert covers the right hostnames but TLS handshake is very slow.

Could be cert chain size (large chain takes longer to download), OCSP stapling not enabled (client must query CA), or generally slow server. The handshake time number is informational. If it’s persistently over 300ms, server-side TLS is the bottleneck.

Tips

  • Auto-renewal is non-negotiable. Manual renewal at 1-year intervals is feasible but always one missed reminder away from outage; at 90-day Let’s Encrypt intervals, manual is impossible.
  • Set monitoring on cert expiry separately from auto-renewal. Both should be in place. The monitoring is the safety net for when auto fails.
  • The SAN list is the most common cert-config error. A cert that covers the bare domain but not www, or vice versa, breaks half your traffic depending on which form users hit.
  • Wildcard certs are convenient but wildcard wildcards (*.*.example.com) are not allowed by the spec. Wildcards cover one level only.
  • If you’re behind Cloudflare, the cert users see is Cloudflare’s, not yours. The cert on your origin server can be self-signed or even absent, but verifying Cloudflare’s cert is what users actually rely on.

Related tools in this suite

The HTTP Headers Inspector covers HSTS, the Strict-Transport-Security header that forces browsers to use HTTPS for the configured period. HSTS and a valid cert work together; missing either weakens HTTPS posture. The Mixed Content Audit catches the related issue of HTTPS pages loading HTTP resources, which weakens the security indicator even when the cert itself is fine. All three tools sit within the SEO Suite.

What this looks like at scale

For a single host, manual cert checks are fine. For organisations with many domains and subdomains, cert monitoring should be automated: alerting on expiry under 21 days, alerting on auto-renewal failure, alerting on cert-chain issues. The WP Beacon Plugin tracks SSL cert expiry across an entire site, and is built as part of our WordPress Development work.

Take it further

If your SSL configuration is inconsistent across many hosts (some auto-renewing, some manual, some misconfigured), the right scope is a cert-management consolidation. A single source of truth for cert status, monitored alerts, automated renewal everywhere. Talk through the setup and we can scope what consolidation looks like.