SSL Lookup
What is an SSL Lookup?
An SSL lookup is a check that connects to a website's server, retrieves its TLS certificate (still commonly called an "SSL certificate"), and reports everything about it: who issued it, which domain names it covers, when it was issued, when it expires, and whether the full certificate chain validates correctly. TLS — Transport Layer Security — is the protocol that puts the padlock in your browser's address bar and the https:// in front of a URL. It encrypts the connection between a visitor and a server so passwords, payment details, and personal data cannot be read or modified in transit.
Every HTTPS website needs a certificate. The certificate is a small digital document, issued by a trusted Certificate Authority (CA) such as Let's Encrypt, DigiCert, Sectigo, or Google Trust Services, that binds a public key to a domain name. When your browser connects to a site, the server presents this certificate; the browser checks that it was issued by a CA it trusts, that it has not expired, that the domain name matches, and that it has not been revoked. If any check fails, the browser shows a warning — "Your connection is not private" — and most visitors leave immediately.
Certificates are not permanent. Publicly trusted certificates now have a maximum validity of 398 days (about 13 months), and free certificates from Let's Encrypt last just 90 days by design. That means every site operator is on a renewal treadmill: miss a renewal and the site breaks for every visitor at once. Certificate expiry remains one of the most common causes of major website outages — it has taken down payment systems, government portals, and household-name tech companies. An SSL lookup is how you see expiry coming before your visitors do.
Beyond expiry, a proper lookup inspects the certificate chain. A server must present not just its own certificate but the intermediate certificates that link it to a trusted root. A missing intermediate is the classic "works in my browser, fails everywhere else" bug: desktop browsers cache intermediates, but mobile apps, APIs, and fresh clients fail. The lookup also reveals the Subject Alternative Names (SANs) — the full list of domains the certificate covers — which catches the common mistake of a certificate that covers example.com but not www.example.com, or that forgot a new subdomain.
Our free SSL lookup performs a live handshake with the server you enter and shows the complete certificate details: issuer, subject, SAN list, validity window with days remaining, signature algorithm, key size, TLS version negotiated, and chain validation status. It is the fastest way to answer "is this site's certificate healthy?" Your query is processed instantly and never stored. For a complete security audit, combine it with our DNS lookup to confirm the domain resolves correctly and our HTTP headers lookup to verify HSTS and other security headers.
How to Use the SSL Lookup Tool
Inspecting any website's certificate takes seconds:
- Enter the domain or URL. Type the website address into the input field — just the domain (e.g.
example.com) is enough. The tool automatically connects on port 443 and performs a real TLS handshake, the same negotiation your browser performs. - Run the lookup. Click the check button. The tool connects to the server, downloads the presented certificate chain, and validates it against the trusted root store, all in a few seconds.
- Check the validity window. The report prominently shows the "valid from" and "valid until" dates plus the number of days remaining. Anything under 30 days deserves a renewal plan now; under 7 days is an emergency. Set a calendar reminder or automate renewal with a CA that supports ACME, such as Let's Encrypt.
- Verify the domain coverage. Review the Subject Alternative Names list. Every hostname visitors use — the apex domain,
www, and each active subdomain — must appear. If a name is missing, visitors to that hostname will see a certificate name-mismatch warning. - Inspect the chain and issuer. Confirm the chain validates fully (leaf → intermediate → trusted root) and note the issuer and signature algorithm. Modern certificates should use SHA-256 with RSA-2048 (or stronger) or ECDSA; anything mentioning SHA-1 or 1024-bit keys is obsolete and untrusted.
- Act on warnings, then re-check. If the lookup flags an expiring certificate, a broken chain, or a name mismatch, fix it at your host or CA, then run the lookup again to confirm the server is presenting the corrected certificate. Pair the check with our WHOIS lookup if you also need to verify who actually owns the domain behind the certificate.
Key Features of the SSL Lookup
Live handshake, real data. The tool does not guess from cached databases — it opens a genuine TLS connection to the server and reads the exact certificate being served right now, including which TLS version was negotiated (TLS 1.2 or 1.3 on any modern setup).
Expiry countdown. The report converts the "not after" date into plain days-remaining, color-coded by urgency. Because public certificates cap at 398 days and Let's Encrypt certificates at 90 days, expiry monitoring is not optional — it is the core of the tool.
Full chain validation. The lookup walks the entire chain from the leaf certificate through every intermediate to a trusted root, flagging missing intermediates, expired intermediates, and self-signed certificates. This catches the failures that only appear on mobile devices, APIs, and embedded clients.
Complete SAN listing. Every Subject Alternative Name on the certificate is listed, so you can verify multi-domain and wildcard coverage at a glance — including whether a wildcard like *.example.com is present (note: wildcards do not cover the apex domain itself, which must be listed separately).
Issuer and algorithm details. See the issuing CA, the signature algorithm, the public-key type and size, and the serial number — everything you need to confirm the certificate meets modern standards and to reference it when talking to your CA or hosting provider.
Private by design. No account and no signup. Your lookups are processed instantly and never stored, logged, or shared.
| Certificate type | What it validates | Typical issuance time | Best for |
|---|---|---|---|
| Domain Validated (DV) | Control of the domain only | Minutes (automated) | Blogs, personal sites, most small businesses |
| Organization Validated (OV) | Domain + verified organization identity | 1–3 days | Companies wanting vetted identity in the cert |
| Extended Validation (EV) | Rigorous legal/operational vetting | Several days to weeks | High-trust brands (no longer shown distinctly in browsers) |
| Wildcard | Domain + all first-level subdomains | Minutes to days | Sites with many subdomains |
| Multi-domain (SAN/UCC) | Multiple unrelated domains | Minutes to days | Portfolios, agencies hosting many client domains |
One honest note: browsers no longer display any special indicator for EV certificates, so for the vast majority of sites a free automated DV certificate from Let's Encrypt provides identical encryption and browser trust to a paid one. What matters is that the certificate is valid, covers the right names, renews automatically, and chains correctly — exactly what this lookup verifies.
SSL Lookup Use Cases
Developers and DevOps engineers
The problem: You manage dozens of services across staging and production. Certificates expire silently, renewals fail quietly (an ACME challenge breaks, a DNS record changes), and the first alert is a flood of user complaints or a broken mobile app that pins certificates.
How this tool helps: Before every release and on a regular schedule, run each public hostname through the SSL lookup. The days-remaining countdown and chain validation catch expiring certs, failed auto-renewals, and missing intermediates before they become incidents. It is also the fastest way to verify a new deployment: confirm the fresh certificate is actually being served (not a cached old one) and that the SAN list covers every hostname the release touches.
SEO specialists and site owners
The problem: Google has used HTTPS as a ranking signal since 2014, Chrome labels HTTP pages "Not secure," and visitors abandon sites that trigger certificate warnings. A mixed-content issue or an expired cert can crater both rankings and conversions, yet the site owner only finds out from an angry customer.
How this tool helps: Include the SSL lookup in every technical SEO audit. Verify the certificate is valid, covers both the www and non-www versions (mismatches here are a classic redirect-chain bug), and has healthy expiry headroom. Combined with our DNS lookup, you can trace whether a certificate problem is really a DNS problem — for example, a stale A record pointing at an old server with an old certificate.
Security-conscious shoppers and researchers
The problem: You are about to enter payment details on an unfamiliar store, or you received a link that looks almost — but not quite — like your bank. Phishing sites increasingly use valid DV certificates, so the padlock alone proves nothing.
How this tool helps: Paste the domain into the lookup and read the certificate like an ID card: who issued it, when (a certificate issued ten minutes ago for a "bank" is a red flag), which exact domain names it covers, and whether the organization field matches a real company. It will not catch every scam — nothing replaces careful URL inspection — but a mismatched or brand-new certificate is a strong signal to stop before you type anything sensitive.
Troubleshooting Common SSL Errors
When this lookup surfaces a problem — or when visitors report browser warnings — the error message usually points at one of a handful of root causes. Here is how to read them.
NET::ERR_CERT_DATE_INVALID / certificate expired. The certificate's validity window has passed. Renew immediately through your CA or hosting panel, install the new certificate, and re-run the lookup to confirm the fresh dates are being served. If you use automated renewal, investigate why it failed before it fails again: check ACME challenge records, DNS delegation, firewall rules blocking the validation path, and disk space. Then set up expiry monitoring so the next renewal is a non-event.
NET::ERR_CERT_COMMON_NAME_INVALID / name mismatch. The certificate does not list the hostname being visited — the classic www vs. apex gap, or a new subdomain added without updating the certificate. The fix is to reissue the certificate with all needed names in the SAN list (or add a wildcard). Our lookup's SAN listing shows exactly which names are covered, so compare it against every hostname your site actually serves.
NET::ERR_CERT_AUTHORITY_INVALID / unknown issuer. The chain does not lead to a trusted root. Causes range from a genuinely self-signed certificate (fine for internal dev, never for public sites) to a missing intermediate certificate — the server sends the leaf but not the chain linking it to the root. Install the CA's intermediate bundle alongside your certificate; the lookup's chain validation confirms when the path to a trusted root is complete.
MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT / SEC_ERROR_UNKNOWN_ISSUER. Firefox's versions of the same trust failures. On corporate networks, these can also be caused by TLS-intercepting proxies presenting their own certificates — if the warning appears only on the office network, ask IT about the proxy's root certificate rather than changing anything on the server.
Mixed content warnings. The page loads over HTTPS but pulls images, scripts, or stylesheets over HTTP. Browsers block the active mixed content (scripts, iframes) and warn on the rest. Fix by serving every subresource over HTTPS — usually a find-and-replace of http:// asset URLs or enabling your CMS's "force HTTPS" setting — and confirm with our HTTP headers lookup that HSTS and upgrade-insecure-requests policies are in place.
Works on desktop, fails on mobile. Almost always a missing intermediate certificate: desktop browsers have deep intermediate caches from years of browsing, while mobile apps and fresh clients validate strictly. The lookup catches this because it validates the chain the way a strict client does — fix it server-side once and it is fixed everywhere.
The general debugging order that resolves most TLS issues: check expiry first, then the SAN list, then the chain, then mixed content, then HSTS and redirect configuration. Work through them in that order and you will rarely need to go further.
Frequently Asked Questions
What is an SSL certificate?
An SSL certificate (technically a TLS certificate — "SSL" is the legacy name everyone still uses) is a digital document issued by a trusted Certificate Authority that binds a cryptographic public key to a domain name. It enables HTTPS: it lets your browser verify it is talking to the real server for that domain and establishes an encrypted connection so data cannot be eavesdropped on or tampered with in transit. Without a valid certificate, browsers show a full-page security warning instead of the site.
How long are SSL certificates valid?
Publicly trusted certificates issued today last a maximum of 398 days (roughly 13 months) — a limit set by the CA/Browser Forum and enforced by browsers. In practice, many sites use Let's Encrypt certificates, which are valid for only 90 days and are designed to be renewed automatically. Shorter lifetimes are a deliberate security trend: they limit the damage if a key is compromised and push the industry toward automation. Check expiry with this tool and automate renewal wherever possible.
What does "certificate chain" mean, and why does a broken chain matter?
A certificate chain is the path of trust from your site's certificate (the "leaf") up through one or more intermediate certificates to a root certificate that browsers already trust. Servers must send the intermediates along with the leaf; the root itself stays in the browser. If an intermediate is missing, desktop browsers often still work (they cache intermediates from other sites), but mobile apps, APIs, payment webhooks, and IoT devices typically fail with a trust error. Our lookup validates the full chain so you catch this before your API consumers do.
What are Subject Alternative Names (SANs)?
Subject Alternative Names are the list of domain names a certificate is authorized to protect, embedded in the certificate itself. Modern browsers ignore the old Common Name field and check only the SAN list. If a visitor reaches a hostname not in the SAN list — say www.example.com when the cert only lists example.com — the browser shows a name-mismatch warning. A wildcard SAN like *.example.com covers all first-level subdomains but not the apex domain or deeper levels like a.b.example.com.
Is a free Let's Encrypt certificate as secure as a paid one?
Yes — the encryption is identical. A free Domain Validated certificate from Let's Encrypt uses the same TLS protocols, the same cipher suites, and the same 2048-bit (or better) keys as a paid DV certificate, and browsers trust it exactly the same way. Paid certificates add value only in specific cases: organization vetting (OV/EV), wildcard or multi-domain coverage in one cert, longer validity, warranties, or dedicated support. For most sites, a free auto-renewing certificate is the best choice.
What should I do if my certificate expires?
Act immediately: every visitor is seeing a security warning and likely leaving. If you use automated renewal (Let's Encrypt, or your host's built-in SSL), check why it failed — common causes are expired ACME DNS challenges, changed DNS records, or a full disk blocking renewal. Renew or reissue the certificate, install it, and then run this lookup to confirm the server is serving the new certificate with a fresh validity window. Then set up monitoring — a weekly automated check of days-remaining — so it never happens again.
Does HTTPS affect SEO?
Yes. Google confirmed HTTPS as a ranking signal in 2014, and it remains a tiebreaker between otherwise equal pages. More importantly, Chrome and other browsers label HTTP pages "Not secure," which depresses click-through rates and conversions, and many modern web features (geolocation, service workers, payment APIs) require a secure context. Migrating to HTTPS is one of the highest-ROI technical SEO tasks — and this tool verifies the migration actually worked.
What is the difference between TLS 1.2 and TLS 1.3?
TLS 1.3 is the current version of the protocol, finalized in 2018. Compared to TLS 1.2, it establishes connections faster (one round trip instead of two), removes support for obsolete and insecure cipher suites and features (like RSA key exchange and CBC-mode ciphers that enabled past attacks), and encrypts more of the handshake itself for better privacy. All modern browsers support TLS 1.3, and servers should offer it while keeping TLS 1.2 enabled for older clients. Anything older than TLS 1.2 should be disabled entirely.