Up to 50 domains per check — one per line or comma-separated. Entries beyond 50 are ignored.
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. Whether you check SSL certificate of website root domains or a single API host, these are the fields that decide whether it works everywhere — and all of them are 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: no account, nothing to configure. If you're wondering how to check SSL certificate details for a domain you don't control, it's the same three steps — here's what happens when you submit one.
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, and each browser has its own name for it. The same missing intermediate certificate is ERR_CERT_AUTHORITY_INVALID in Chrome, SEC_ERROR_UNKNOWN_ISSUER in Firefox and error 21 in OpenSSL — so find the row for what you're seeing, then read across.
| What's actually wrong | Chrome & Edge | Firefox | Safari / command line | Fix |
|---|---|---|---|---|
| Domain isn't listed in the certificate | ERR_CERT_COMMON_NAME_INVALID | SSL_ERROR_BAD_CERT_DOMAIN | NSURLErrorServerCertificateUntrusted (-1202) | Reissue with every hostname in the SAN list — including the www variant |
| Certificate has expired | ERR_CERT_DATE_INVALID | SEC_ERROR_EXPIRED_CERTIFICATE | NSURLErrorServerCertificateHasBadDate (-1201) · curl (60) certificate has expired | Renew it, then confirm the server is actually serving the new file |
| Not valid yet, or the clock is wrong | ERR_CERT_DATE_INVALID | SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE | NSURLErrorServerCertificateNotYetValid (-1204) | Check the server's NTP sync before touching the certificate |
| Intermediate certificate missing from the chain | ERR_CERT_AUTHORITY_INVALID | SEC_ERROR_UNKNOWN_ISSUER | NSURLErrorServerCertificateHasUnknownRoot (-1203) · OpenSSL verify error 21 | Serve the full chain (leaf + intermediates). Browsers differ here, so it often "works" in one and not another |
| Self-signed certificate | ERR_CERT_AUTHORITY_INVALID | MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT | OpenSSL verify error 18 / 19 | Fine for internal tools; use a publicly trusted CA for anything users reach |
| Certificate was revoked | ERR_CERT_REVOKED | SEC_ERROR_REVOKED_CERTIFICATE | Safari: "This Connection Is Not Private" | Reissue. If it was revoked for key compromise, generate a new key pair too |
| Plain HTTP being served on the HTTPS port | ERR_SSL_PROTOCOL_ERROR | SSL_ERROR_RX_RECORD_TOO_LONG | curl (35) wrong version number | Fix the vhost — something is listening on 443 without TLS |
| No TLS version or cipher in common | ERR_SSL_VERSION_OR_CIPHER_MISMATCH | SSL_ERROR_NO_CYPHER_OVERLAP | curl (35) handshake failure | Enable TLS 1.2 and 1.3. Old clients hitting a modern-only config produce the same error |
| Deprecated TLS version still in use | ERR_SSL_OBSOLETE_VERSION (warning) | SSL_ERROR_PROTOCOL_VERSION_ALERT | OpenSSL: no protocols available | Disable TLS 1.0 and 1.1 — they fail PCI DSS and are rejected by modern clients |
| Weak signature algorithm (SHA-1) | ERR_CERT_WEAK_SIGNATURE_ALGORITHM | SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED | Safari refuses the connection outright | Reissue with SHA-256 or better |
| Traffic is being intercepted | ERR_CERT_AUTHORITY_INVALID | MOZILLA_PKIX_ERROR_MITM_DETECTED | Issuer shows as antivirus or a corporate proxy | Usually local TLS-inspecting antivirus or a company proxy — not your server. Verify from outside the network |
| Certificate Transparency proof missing | ERR_CERTIFICATE_TRANSPARENCY_REQUIRED | (not enforced) | Safari enforces its own CT policy | Reissue through a CA that publishes to CT logs — any modern public CA does |
| Client certificate required or rejected | ERR_BAD_SSL_CLIENT_AUTH_CERT | SSL_ERROR_HANDSHAKE_FAILURE_ALERT | curl (58) unable to use client certificate | Check mutual-TLS config — the server is asking for a client certificate |
Seeing an error in one browser but not another almost always means an incomplete chain: browsers that happen to have cached the intermediate succeed, and the rest fail. Test from a machine that has never visited the site.
Want expiry checked for you?
Manual checks catch problems after they happen. nslookup.io can watch your certificates and warn you before one expires.
Set up automated SSL monitoring →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, so check monthly. For commercial certificates that expire after 1–2 years, check quarterly. If you'd rather not remember, SSL monitoring checks daily for you.
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.
Yes — the SSL checker is completely free. There's no account to create, no rate limits for typical usage, and nothing you check is stored. Run it as often as you like, on any domain.
SSL health doesn't exist in isolation. These tools help you check the full stack.