SSL Certificate Checker: How to Verify TLS Config Like an SRE

An ssl certificate checker answers one question: will this cert work for the clients you care about, right now, and for how much longer. Most checkers stop at "chain looks fine, padlock is green" and miss the half-dozen ways a certificate can be technically valid but operationally broken. According to incident data from production TLS deployments, roughly 30% of cert failures are drift issues that point-in-time checkers never catch. If you've ever had a 2am page because one load balancer node was still serving last quarter's cert, you know the gap between a passing check and a passing deployment.

This is a practitioner's walkthrough: command-line checks you can paste into a terminal right now, an honest comparison of the web tools, the failure modes each tool catches, and the point where one-off checking stops working and you need something running on its own.

What an SSL Certificate Checker Actually Validates

A real ssl certificate checker validates six things:

• Chain completeness from leaf to a trusted root
• Signature validity on each link in the chain
• Hostname/SAN match against the requested host
• Validity window (NotBefore and NotAfter dates)
• Signature algorithm and key strength
• Revocation status via OCSP or CRL

Miss any of those and you're guessing, even if your browser shows a padlock. Proper tls certificate verification means checking all six, not just the ones that fire obvious errors.

Chain of trust verification

Every leaf certificate is signed by an intermediate, which is signed by a root. Your server must serve the leaf plus every intermediate up to (but not including) the root. The root is already in the client's trust store. "Incomplete chain" means the server didn't send an intermediate and the client had nowhere to get it.

Browser behavior diverges sharply here:

• Chrome and modern browsers: fetch missing intermediates from the AIA extension
• Most API clients, mobile apps, older Java HTTP stacks: do not fetch, fail outright

This is why a cert can look fine in Chrome and break everything else.

Hostname and SAN matching

Since 2017, Chrome has ignored the Common Name field entirely. Hostname validation uses the Subject Alternative Name extension, period. A cert with CN=example.com and no SAN containing example.com fails validation in every modern client.

Wildcard rules: *.example.com covers api.example.com but not api.eu.example.com. Wildcards match exactly one level. If your checker doesn't explicitly print the SAN list, it isn't doing this check.

Expiration and validity windows

NotBefore and NotAfter are the real validity boundaries. A cert served before NotBefore is as broken as one served after NotAfter. This bites teams on backdated issuance, clock skew on long-running VMs, and internal CAs where nobody noticed the issuing CA itself expired.

The CA/Browser Forum ballot dropping public lifetimes to 47 days by 2029 means NotAfter is going to be much closer than most runbooks assume, so your ssl certificate expiration check logic needs to tolerate shorter windows.

Revocation status (OCSP/CRL)

OCSP gives you a yes/no on whether a specific cert has been revoked. OCSP stapling lets the server prefetch and serve that answer so the client doesn't need to reach the CA. In practice, stapling is silently broken on a significant share of endpoints we measure. OCSP stapling is probably broken on half your endpoints is not hyperbole. A proper ocsp stapling check looks at the stapled response bytes in the TLS handshake, not just whether the feature flag is on.

How to Check an SSL Certificate from the Command Line

The fastest way to check ssl from command line is openssl s_client. One binary, installed everywhere, shows every byte the server handed back. In my experience working incident response on TLS issues, about 80% of the failures get diagnosed with openssl in under two minutes. Web tools are fine but slower, rate-limited, and often cache stale results. For anything mid-incident, the terminal wins.

openssl s_client one-liners

The basic openssl check certificate incantation:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

That gets you subject, issuer, NotBefore, NotAfter, and SANs in one call. -servername sets SNI, which you almost always want on shared hosts. The </dev/null closes stdin so the handshake completes and the command returns.

Checking intermediate chain with -showcerts

To see what the server actually sent, add -showcerts:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Count the -----BEGIN CERTIFICATE----- blocks. Interpretation:

• 1 block: leaf only — half your clients will fail
• 2-3 blocks: usually correct (leaf plus intermediates)
• Root included: wastes bytes; some validators reject it

The verify result line to watch:

Verify return code: 0 (ok)

If it says unable to get local issuer certificate, your chain is broken or your local CA bundle is missing a root. Which one depends on whether other hosts return 0 (ok) against the same bundle.

Verifying SNI-based multi-cert hosts

Modern load balancers serve different certs for different hostnames on the same IP. Always pass -servername explicitly. Forgetting it is why "the cert looks wrong" turns into "I was hitting the default vhost." I've watched engineers waste thirty minutes on this exact mistake.

curl -vI for quick sanity checks

curl -vI https://example.com 2>&1 | grep -E "SSL|subject|issuer|expire"

curl shows the negotiated cipher, the cert's subject, and the date it expires. It uses the system CA bundle, so a failure here tells you how a typical API client will see your endpoint, which is often very different from what Chrome sees.

nmap ssl-enum-ciphers for protocol/cipher inventory

For protocol and cipher inventory, nmap --script ssl-enum-ciphers -p 443 example.com enumerates every TLS version and cipher the server accepts and rates each one. This is the fastest way to find a host still negotiating TLS 1.0 or a dead cipher suite. ssl troubleshooting that starts with "what is this server even willing to speak" should start here.

Web-Based SSL Certificate Checkers Compared

Web checkers vary enormously in what they actually test. SSL Labs (Qualys) is the only free tool that grades protocol and cipher config seriously. Most others are glorified "does the cert expire soon" displays. Picking the right one depends on whether you want a grade, a chain dump, or a fast answer in a Slack thread.

Tool	Chain validation	Cipher grading	Client simulation	Speed	Best for
SSL Labs (Qualys)	Full	A+ to F grade	40+ user agents	Slow, ~18hr cache	Defensible audit grade
DigiCert SSL Checker	Chain depth, SAN, basic revocation	None	None	Fast	Quick chain check
SSLShopper	Chain, expiration, SAN	Minimal	None	Fast	Casual lookup
SSL.org / whynopadlock	Missing intermediate, mixed content	None	None	Fast	"Why is my padlock broken?"

SSL Labs probes IPv4 and IPv6, validates OCSP and stapling, checks HSTS, and is rate-limited when the queue is deep. Still the only tool that gives you an ssl labs test grade worth defending in a review.

When browser DevTools is enough: for a single host, open the site, click the padlock, check the cert details. DevTools under the Security tab shows the full chain, signature algorithm, and validity. If you only need "is the cert on this one host OK right now," this is faster than any web tool. It won't test cipher config or IPv6, but neither will most of the web tools.

For hundreds of public endpoints, neither web tools nor DevTools scales. That's a different problem, which we'll get to.

The Failure Modes a Checker Catches (and the Ones It Won't)

Point-in-time checkers catch roughly 70% of real TLS incidents. The other 30% are drift: the cert is fine on five of six LB nodes, the CDN origin re-pinned to an old cert after a cache flush, the internal CA expired while nobody was looking. Here's how to think about both.

Missing intermediate certificate

• Symptom: unable to get local issuer certificate from curl, SSLHandshakeException: PKIX path building failed from Java clients, Chrome works fine
• Root cause: server sending leaf only
• Fix: concatenate intermediates into the cert bundle the server reads
• Detection: a checker that counts chain certs catches this instantly

This is the single most common failure we see, and the reason a certificate can work in Chrome but break everywhere else.

Expired or soon-to-expire leaf

Every tool checks this first, and it remains the number one incident cause. According to Let's Encrypt data from 2024, roughly 1 in 10 certs are renewed within 7 days of expiry, which is far too close. If your renewal window is tighter than 14 days, you have no room for a failed ACME challenge.

Wrong hostname / SAN drift

A cert reissued with a subset of the original SANs quietly breaks a subdomain. The Slack bot at hooks.internal.example.com starts erroring, and the team that owned the renewal never realized the SAN was dropped. A good checker diffs the SAN list against the previous issuance. Most don't.

Weak signature algorithms (SHA-1, RSA-1024)

Public CAs stopped issuing SHA-1 in 2016 and RSA-1024 years before that. Internal CAs don't always get the memo. If your checker doesn't surface the signature algorithm, you can be running SHA-1 on internal infra and not know until a Go 1.18+ client refuses to connect. openssl x509 -text -noout shows it; use that as ground truth.

What one-shot checkers miss

Three drift patterns no web tool catches:

• Load balancer node drift: a rolling cert rotation failed halfway through. Five nodes serve the new cert, one serves the old. Every sixth request fails. A web checker hitting the VIP sees one node at random and gives you a green check. What happens when your certificate renews but doesn't deploy is exactly this pattern.
• CDN origin re-pinning: the edge cert is fine, the origin cert expired last week, and the CDN is happily serving cached responses. When cache expires, origin fetches start failing. No external checker sees the origin.
• Internal CA expiry: an intermediate on the internal PKI expires on a Saturday. Every service cert issued from it is now untrusted, regardless of the cert's own NotAfter. A public checker cannot see internal CAs at all.

From One-Off Checks to Continuous Certificate Monitoring

Manual checking works until about 50 certs. Past that threshold, the math stops working: with 200 certs on a 90-day renewal cycle, you're renewing more than two per day on average, and a single miss is a production incident. Continuous certificate monitoring moves you from "I'll check when I remember" to "something pages me when a cert is 30 days from expiry or drifts from its peers."

Why manual checking fails at 50+ certificates

The 50-cert threshold isn't arbitrary. It's roughly where a single engineer's head-model of "which certs exist, who owns them, when they renew" stops fitting in working memory. Below 50, a calendar reminder and a quarterly SSL Labs sweep is fine. Above it, you need an inventory with owners, renewal state, and alerting, or you're one vacation away from an outage.

What continuous monitoring adds

Continuous monitoring watches every endpoint on a schedule, alerts on drift between nodes, and tracks the renewal lifecycle. Key differences versus a one-off check:

• Coverage: every endpoint, every node, not just the VIP
• Historical data: you see drift instead of a snapshot
• Alerting: integrated with PagerDuty, Slack, or whatever your team actually reads
• Internal PKI visibility: covers what public tools can't reach

CT log watching for shadow certs

Every publicly trusted cert issued since 2018 gets logged in Certificate Transparency logs within 24 hours. CT log monitoring means watching those logs for certs issued on your domains that nobody on your team requested. This is how you catch:

• Shadow IT (marketing team spun up a subdomain on a different CA)
• Typosquatting domains
• Compromised ACME accounts

No public checker does this. If you want the deeper dive, Certificate Transparency logs aren't just for browsers covers the setup.

Alerting thresholds that actually work

After tracking renewal cadence data across several thousand certs, the thresholds that balance signal and noise:

Days to expiry	Action	Channel
90 days	Informational	Inventory dashboard
30 days	Ticket the owner	Manual renewals start
7 days	Page someone	Automation should have fired
1 day	Wake the on-call	Service owner

Anything sooner than 7 days without automation is a bug in your process. CertPulse ships with these thresholds as defaults because they match what we've seen work in practice.

FAQ

Is there a free ssl certificate checker?

Yes, several. SSL Labs (ssllabs.com/ssltest) is the most thorough free web checker and gives a letter grade on protocol and cipher config. For command line, openssl s_client, curl -vI, and nmap --script ssl-enum-ciphers are free and installed by default on most Linux distros. Browser DevTools under the Security tab is free and often sufficient for single-host checks.

How do I check an SSL certificate without a browser?

Run openssl s_client -connect host:443 -servername host </dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName. That returns subject, issuer, validity dates, and SANs in one shot. For the full chain, add -showcerts. For cipher inventory, use nmap --script ssl-enum-ciphers -p 443 host. None of those need a browser or internet-accessible tool.

What does "certificate chain incomplete" mean?

The server sent the leaf certificate but not the intermediate(s) needed to build a path to a trusted root. Chrome often compensates by fetching missing intermediates via the AIA extension; curl, Java HTTP clients, and most mobile SDKs don't. The fix is to rebuild your server's cert bundle to include leaf plus all intermediates, in order, terminating just below the root.

How often should I check my certificates?

For fewer than 50 certs, a monthly manual sweep plus a calendar reminder 30 days before expiry is enough. Past 50, you need continuous automated checking (every 15 to 60 minutes per endpoint is typical) with alerting at 30, 7, and 1 day before expiry. Drift detection should run at least hourly so you catch load balancer rotation failures before users do.

Can a checker validate internal / private CA certs?

Public web tools cannot, because they don't trust your internal CA. Command-line tools can if you point them at your internal CA bundle: openssl s_client -CAfile /path/to/internal-ca.pem -connect internal-host:443. Continuous monitoring tools need an agent or reachable probe inside the network perimeter to see internal endpoints at all. This is where most "fleet monitoring" SaaS products quietly give up.

---

An ssl certificate checker gets you 80% of the way on any single host, any time you need it. The openssl commands above will catch most real issues faster than any web tool. The remaining 20% — drift, shadow certs, the internal CA nobody's watching — is what eats teams alive once the fleet grows past 50 certs. That's where continuous monitoring stops being optional and starts being the difference between a boring week and a postmortem. CertPulse monitors TLS certificates around exactly that gap.