Most SSL checkers just tell you "valid" or "invalid." That's not enough. A certificate can be technically valid and still cause browser errors, block mobile users, or expose a weak cipher. Here's what we inspect.
We walk the chain from your leaf certificate up through every intermediate CA to the root. Missing an intermediate is the most common cause of SSL errors that your own browser doesn't catch but mobile users and some APIs do.
Exact UTC timestamp plus a visual countdown. We flag anything under 30 days. If you're on Let's Encrypt and your auto-renewal has silently failed, this is where you find out.
The SANs list shows exactly which domains and subdomains your certificate covers. Critical to check after any renewal — some automated tools issue new certs that miss a subdomain from the old one.
We report the exact protocol version negotiated (TLS 1.2 or 1.3) and cipher suite. TLS 1.0 and 1.1 were deprecated in 2020. If your server still offers them, PCI DSS compliance will flag it.
Who issued it and what kind: DV (domain validated), OV (organisation validated), or EV (extended validation). Matters if you're troubleshooting why certain enterprise proxies are blocking your connections.
Useful when you need to verify a specific certificate is installed — not just any valid cert. Common in zero-trust setups where you pin expected certificate fingerprints.
The tool is deliberately simple. You don't need an account, and there's nothing to configure. Here's what happens when you submit a domain.
Type any domain — example.com, api.example.com, mail.example.com. You can include or drop the https:// prefix, it doesn't matter. For non-standard ports, use example.com:8443.
nslookup.io connects to your domain on port 443 (or the port you specify), performs the TLS handshake, and pulls the actual certificate the server is currently serving. We check from multiple locations to avoid caching edge cases. No data is stored.
Results show validity status, exact expiry timestamp, every certificate in the chain with issuer details, all SANs, cipher suite, and TLS version. Problems are flagged in red or amber so you don't have to hunt for them.
If you're building tooling, running automated checks in CI/CD, or using an AI assistant that supports MCP, you can access the SSL checker programmatically.
GET https://api.nslookup.io/v1/ssl?domain=github.com Authorization: Bearer YOUR_API_KEY # Returns: issuer, expiry, daysUntilExpiry, chainValid, # sanDomains, cipher, protocolVersion, fingerprint
# Add to your MCP config:
{
"mcpServers": {
"nslookup": {
"url": "https://mcp.nslookup.io/mcp"
}
}
}
# Then in Claude, Cursor, or any MCP-compatible client:
# "Check the SSL certificate for api.example.com"
# → Returns live certificate data directly in your conversationThe MCP integration is particularly useful for teams running AI-assisted infrastructure reviews — you can check SSL status alongside DNS records, DMARC, and uptime from a single conversation without switching tools.
When your server sends a certificate, it should send the entire chain: your domain's certificate, plus the intermediate CA certificate that issued it. Browsers already have the root CA in their built-in trust store. But they don't have the intermediate — they need your server to provide it.
If the intermediate is missing, most desktop browsers will try to fetch it automatically and usually succeed. But mobile browsers, IoT devices, and many API clients won't do this. They'll just show an error. That's why certificate chain errors are the most common bug that "works on my machine" — you tested it in Chrome on a Mac.
# Quick chain check from the command line: openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null # How many certificates do you see? You should see at least 2. # If you only see 1, the intermediate is missing.
Everyone says "SSL" but what's actually running is TLS. SSL 2.0 and 3.0 are both dead — they were deprecated years ago after critical vulnerabilities. TLS 1.0 and 1.1 were deprecated in March 2020 (RFC 8996). The current standard is TLS 1.3 (RFC 8446, 2018), with TLS 1.2 still acceptable.
| Protocol | Status | Should you use it? |
|---|---|---|
| SSL 2.0 / 3.0 | Deprecated 2015 | No — disable immediately |
| TLS 1.0 / 1.1 | Deprecated 2020 | No — breaks PCI DSS compliance |
| TLS 1.2 | Acceptable | Yes, but upgrade to 1.3 where possible |
| TLS 1.3 | Current standard | Yes — faster handshake, stronger security |
| Type | What's verified | Issuance time | Best for |
|---|---|---|---|
| DV (Domain Validated) | You control the domain | Minutes | Most websites, APIs, Let's Encrypt |
| OV (Organisation Validated) | Domain + legal organisation | 1–3 days | Business websites needing org name in cert |
| EV (Extended Validation) | Domain + org + legal identity | 1–5 days | Financial services, enterprise, high-trust |
Every error has a specific cause. Knowing the error code tells you exactly where to look.
| Error | Root cause | Fix |
|---|---|---|
| ERR_CERT_COMMON_NAME_INVALID | Domain not in SANs | Reissue cert with correct SANs |
| ERR_CERT_DATE_INVALID | Expired or clock skew | Renew cert, check NTP sync |
| ERR_CERT_AUTHORITY_INVALID | Self-signed or missing intermediate | Install full certificate chain |
| SSL_ERROR_RX_RECORD_TOO_LONG | HTTP on HTTPS port | Fix server port configuration |
| ERR_SSL_PROTOCOL_ERROR | TLS version mismatch | Enable TLS 1.2/1.3 on server |
Manual checks catch problems after they happen. Monitoring catches them before. nslookup.io checks your SSL certificates daily and alerts you when expiry is approaching — so you're never caught off-guard by a renewal failure.
Start free SSL monitoring →See how monitoring works ↓SSL certificate expiry is one of the most preventable causes of outages. A 90-day Let's Encrypt cert that renews automatically is fine — until the renewal job silently fails because of a DNS change, a firewall rule, or a misconfigured cron job. By then, you've already got a broken site.
nslookup.io's SSL monitoring runs daily checks from multiple locations. We don't just check whether a cert exists — we validate the full chain, verify the hostname matches, and confirm the TLS version is acceptable. Here's how alert timing works:
| Days to expiry | Alert frequency | Severity | Recommended action |
|---|---|---|---|
| 30 days | Single alert | Notice | Schedule renewal if not already queued |
| 14 days | Every 2 days | Warning | Renew now — don't wait for auto-renewal |
| 7 days | Daily | Urgent | Escalate — manual intervention likely needed |
| Expired | Every hour | Critical | Emergency renewal — site is down or broken |
| Chain broken | Immediate | Critical | Fix server config — mobile users affected |
Alerts go wherever your team actually responds: email, Slack, webhook, PagerDuty, or SMS. You can configure different channels for different severity levels — get a Slack message at 30 days, a PagerDuty alert at 7 days.
POST https://api.nslookup.io/v1/monitors
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json
{
"type": "ssl",
"domain": "api.example.com",
"alertAt": [30, 14, 7],
"channels": ["slack", "email"]
}
# Returns: monitorId, nextCheck, currentStatusIf you manage SSL certificates across multiple clients or domains, the monitoring dashboard shows all certificates in one view — sorted by days to expiry, with one-click renewal reminders. The API lets you programmatically pull certificate status across your entire portfolio, which is useful for building custom reporting dashboards or integrating into existing ITSM workflows.
For developers and sysadmins who prefer terminal access, here are the commands we use internally.
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \ | openssl x509 -noout -enddate
openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null
# Test TLS 1.3 support: openssl s_client -connect example.com:443 -tls1_3 </dev/null 2>/dev/null | head -3 # Test whether old TLS 1.0 is still enabled (it shouldn't be): openssl s_client -connect example.com:443 -tls1 </dev/null 2>/dev/null | head -3
openssl x509 -in cert.pem -noout -text -certopt no_header,no_version,no_pubkey
#!/bin/bash DOMAIN="example.com" EXPIRY=$(echo | openssl s_client -servername $DOMAIN -connect $DOMAIN:443 2>/dev/null \ | openssl x509 -noout -enddate | cut -d= -f2) echo "$DOMAIN expires: $EXPIRY"
The fastest way is to use the checker above. Enter your domain and click Check. You'll see whether the certificate is currently valid, the exact expiry date, whether the chain is complete, and all the hostnames covered. If you want to do it from the command line, run: echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates
Nine times out of ten, it's a missing intermediate certificate. Your leaf cert is valid, but the server isn't sending the intermediate that connects it to the trusted root. Desktop Chrome usually handles this silently by fetching the intermediate from the URL in the AIA extension. But mobile Safari, older Android browsers, and most API clients don't do this — they just fail. Run our checker and look at the chain section. If you only see one certificate instead of two or three, that's your problem.
For Let's Encrypt certificates (90-day validity), the renewal should be automatic via certbot or your hosting provider. But automation fails silently — check monthly and set monitoring alerts at 30, 14, and 7 days before expiry. For commercial certificates that expire after 1–2 years, check quarterly. The safest approach is automated monitoring — use nslookup.io's SSL monitoring and you won't have to remember to check manually.
SSL (Secure Sockets Layer) is the predecessor protocol — SSL 2.0 and 3.0 are both long deprecated due to serious vulnerabilities. What you're actually running today is TLS (Transport Layer Security). When people say "SSL certificate" they mean a TLS certificate. The current standard is TLS 1.3 (2018), with TLS 1.2 still widely supported and acceptable. TLS 1.0 and 1.1 were deprecated in 2020 and should be disabled — especially if you're handling payment card data, where PCI DSS requires TLS 1.2 minimum.
Yes. The nslookup.io API lets you check any domain's SSL certificate and get back structured JSON with all fields — issuer, expiry, days remaining, chain validity, SANs, cipher, and TLS version. We also support MCP (Model Context Protocol), which means you can call the SSL checker directly from Claude, Cursor, or any MCP-compatible AI tool without writing API integration code yourself. See the API section above for examples.
The manual SSL checker is completely free — no account, no rate limits for typical usage, no data stored. Automated monitoring (daily checks, expiry alerts, Slack/email notifications) is free for up to 5 domains. For larger portfolios or API access beyond the free tier, see our pricing page.
SSL health doesn't exist in isolation. These tools help you check the full stack.