Test an SSL certificate online (live check)

To test ssl certificate online, complete a live TLS handshake against the public hostname and read notAfter, issuer, and SAN—not a PEM file from last week’s backup.

Product owners, freelancers, and small teams often need a quick answer without SSH access. Free online checkers advertise one-click results, while power users prefer openssl from a laptop. Both are valid when they inspect what the internet receives on port 443 with correct SNI.

The mistake is pasting an internal URL into a public checker, or trusting a screenshot of certificate files in hosting panels while the live site still serves an old chain. Panels can show the renewed cert before the web server reloads.

This guide covers what a legitimate online test validates, how to run equivalent free checks yourself, and how to interpret success versus “certificate has expired” errors.

What to check

A proper online SSL test performs (or simulates) a client TLS handshake to your hostname. It should return:

• Leaf validity window with notBefore and notAfter
• Subject and Subject Alternative Names covered by the cert
• Issuer and whether the chain appears complete
• Sometimes TLS version and cipher (separate from expiry)

It should not require you to upload private keys. Any service asking for your key material to “test” is a red flag.

Separate certificate expiry from domain registration expiry. Registrar billing lapses can block renewals even when notAfter still looks fine. Free TLS checkers rarely show RDAP; add a domain lookup when planning renewals.

Test the exact hostname users enter, including www vs apex. Follow one redirect manually if marketing links hop hostnames, because each hop can present a different certificate.

Free online checkers differ in vantage (US-only POPs), redirect following, and whether they validate chain trust strictly. Treat them as convenient witnesses, not magic—when stakes are high, repeat the same hostname with local openssl and compare serial numbers.

Document whether the checker queried IPv4, IPv6, or both. Half the internet still forgets IPv6 listeners serving an older cert while IPv4 looks renewed.

Step-by-step

Use at least two methods—browser padlock inspection plus a command-line live check—before you tell stakeholders the site is healthy.

Browser (no install)

1. Open https://HOSTNAME/ in Chrome or Firefox.
2. Open the lock icon → connection is secure → certificate details.
3. Record Valid to / Expires on and compare with today’s date.

Detailed padlock steps live in view SSL certificate in Chrome and view certificate in Firefox.

OpenSSL (free, local)

HOSTNAME=example.com
echo | openssl s_client -connect "${HOSTNAME}:443" -servername "${HOSTNAME}" 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer -ext subjectAltName

SNI must match the public DNS name from the address bar.

curl quick verification

curl -vI --connect-timeout 20 "https://${HOSTNAME}/" 2>&1 | head -n 40

SNI must match the hostname you type. curl must complete without -k for a valid sign-off.

A clean result prints HTTP headers after TLS succeeds. Lines mentioning SSL certificate problem or certificate has expired mean verification failed—fix the server cert, not the client.

PowerShell on Windows

$HostName = "example.com"
curl.exe -vI "https://$HostName/" 2>&1 | Select-Object -First 40

curl.exe on Windows matches the bash probe above.

Many teams also use the site’s free check form (same origin as this guide) to run an external vantage when laptops sit behind corporate TLS inspection. External checks catch CDN splits internal tools miss.

After renewal, rerun the same commands and confirm serial and notAfter changed. Store outputs in the ticket for auditors.

Follow redirects explicitly when testing marketing short links:

curl -vIL --connect-timeout 20 "https://HOSTNAME/" 2>&1 | grep -Ei '^(\*|>|<) |expire|SSL certificate'

grep here surfaces TLS errors in long redirect chains.

Each hop in a redirect chain may present a unique cert. Free checkers that stop at hop one miss the failing terminal host.

How to read the output

notAfter= is the hard stop for clients. If that timestamp is in the past, strict browsers and curl fail regardless of hosting panel green icons. Compare in UTC if your team spans time zones.

subject= and X509v3 Subject Alternative Name must include the hostname in the address bar. A valid future notAfter on the wrong name still triggers name mismatch errors.

issuer= tells you whether you expected Let’s Encrypt, a commercial OV cert, or a corporate CA. After migration, issuer changes even when SANs stay constant—update documentation.

For curl, HTTP/2 200 or HTTP/1.1 200 after TLS means verification passed with default trust stores on that machine. A machine with outdated roots might fail trust while the general public succeeds—note environment when escalating.

Online checker UIs usually summarize days remaining. Treat “30 days left” as a warning to finish automation testing, not as approval to ignore renewal until day 29.

Some checkers display issuer organization differently than openssl (abbreviated names). Align on serial and SHA-256 fingerprint when wording differs.

Green “all good” badges may still list warnings (weak ciphers, TLS 1.0). Those warnings are not expiry problems—capture them for hardening tickets separately so renewal engineers are not pulled into cipher debates mid-incident.

Common mistakes

Uploading certificate files to random websites “for testing” leaks organizational details and skips the real question: what the listener serves. Prefer handshake-based checks.

Testing only from the office VPN can show an internal MITM or split-horizon DNS view. Use mobile data or an external monitor for confirmation.

Confusing self-signed staging certs with production: free online tools against staging.example.com may look “broken” by design. Label environments in inventory so alerts route correctly.

Running checks against IP addresses without SNI often hits a default certificate with unrelated notAfter. Always use -servername matching public DNS.

Sharing checker URLs in public Slack channels leaks which brands you worry about and invites third-party scanners to hammer your site. Prefer internal openssl transcripts for sensitive codenames; use public checkers only when policy allows.

Freelancers sometimes test localhost HTTPS tunnels tunnels through ngrok while customers use the production CNAME. Label environment in screenshots before sending them to clients.

When to use automation

One-off online tests fit ad-hoc questions; production needs scheduled live TLS monitoring on every revenue hostname. Automate alerts at 30/14/7/1 days before notAfter, plus immediate pages on verification failure.

Wire the same openssl one-liner into CI after deploys. External services like ssldays provide email or dashboard reminders without replacing your CA workflow.

For deep configuration audits, add occasional SSL Labs test and certificate expiry runs, but keep live handshake checks as the source of truth for expiry incidents.

Embed the free check link in customer status pages only after you trust its rate limits; spikes during outages can trigger WAF rules if checkers poll aggressively.

Offer tier-1 support a laminated card with three commands: Chrome padlock steps, openssl one-liner, and the free check URL—uniform output reduces mis-triage on phone calls.

When negotiating SLAs, define “SSL healthy” as live verification success on named hostnames, not “we ran an online test once at contract signing.”

Agencies managing dozens of small business sites should standardize on one openssl snippet in their runbook rather than bookmarking five different checker UIs with uneven redirect logic.

Educational institutions often block student laptops from installing openssl while still allowing browsers—teach padlock expiry reading first, then lab machines with openssl for computer science tracks.

Webhook receivers (Stripe, GitHub, Microsoft Graph) fail TLS independently of your marketing homepage. Maintain a checklist column “online test run against callback URL” after every cert rotation affecting API subdomains.

Certificate Transparency search consoles complement online tests by showing issuance timestamps when you suspect a checker cached pre-renewal data—search the public hostname and compare SCT dates with live serial numbers.

Rate-limit your own manual testing during incidents; hammering the same host with ten checkers while customers retry can amplify DDoS-like load on small origins.

Smaller teams without dedicated security staff should pick one browser path and one openssl snippet and practice quarterly. Muscle memory beats hunting blog posts during the first expiry scare.

E-commerce peak seasons (Black Friday, tax filing week) are the worst time to learn online checkers behave differently behind bot management. Pre-validate commands against staging mirrors before peak traffic.

When clients ask for “proof the cert is valid,” send a redacted openssl transcript with serial and notAfter, not a marketing checker’s aggregated score alone.

Hosting control panels (cPanel, Plesk) display future scheduled renewal while still serving old material until cron runs—always pair panel screenshots with live online tests immediately after clicking renew.

Franchise brands using per-location subdomains need a matrix: each row is a location code, columns are last online test date and notAfter. Corporate wildcard renewals do not excuse stale per-location DNS mistakes.

Podcast and newsletter teams often hotlink HTTPS sponsors mid-send. Pre-flight online tests on outbound link hostnames hours before send, not only the corporate homepage.

Accessibility consultants auditing secure forms still need certificate dates for VPAT attachments—browser padlock paths satisfy auditors who cannot run bash.