Free SSL certificate checker — verify validity, chain of trust, TLS versions, expiry, and fingerprints for any website.

Six independent classes of information are returned per check. Validity and chain are the headlines; protocol matrix and fingerprints are the diagnostic detail.

TLS misconfigurations are the most common cause of preventable outages, the most common audit finding, and the easiest class of mistake to catch automatically. Five recurring failure modes that an SSL check catches:

• Certificate expiry takes sites down regularly. Microsoft, LinkedIn, GitHub, Equifax, and almost every Fortune 500 have all had public outages caused by an expired cert in the last decade. Automated renewal (Let's Encrypt, ACME) helps, but breaks silently when the renewal process itself has issues. A daily SSL check is the cheapest insurance policy in operations.
• Deprecated protocols still in production expose users. TLS 1.0 was deprecated by IETF in 2021. TLS 1.1 alongside. Both are vulnerable to BEAST, and TLS 1.0 also to POODLE-equivalent attacks. They're still enabled on a surprising number of production servers because nobody audits them after the initial setup.
• Chain misconfigurations break for some clients only. Servers that don't send intermediate certs in the handshake work in Chrome (which fetches missing intermediates via AIA) but fail in Java, curl, mobile apps, and older browsers. The check passes superficially while a meaningful slice of clients silently break.
• Hostname mismatch is invisible until users hit it. A cert valid for example.com but not www.example.com (or vice versa) shows a security warning in the browser. Easy to miss in deploy testing if you only test one of the two names.
• Compliance regimes require modern TLS. PCI DSS, HIPAA, SOC 2, and most industry frameworks mandate TLS 1.2 minimum and forbid SSL 3.0 / TLS 1.0 / TLS 1.1. An automated SSL check is the cheapest way to keep audit evidence current.

We perform an actual TLS handshake against the target on port 443 (configurable), capture the certificates presented during the handshake, then parse and validate each one. The check observes what the server actually serves — not what its config file claims.

• Stage 1 — Connect on port 443 Open a TCP connection to the host. Send TLS ClientHello with all four TLS versions advertised (1.0 through 1.3) so the server reveals its full supported set.
• Stage 2 — Capture the handshake Record the server's ServerHello, including the negotiated protocol version, cipher suite, and the full certificate chain it sends back.
• Stage 3 — Parse each certificate Extract subject, issuer, validity, serial, SAN entries, public key info, signature algorithm, fingerprints. Done per certificate in the chain.
• Stage 4 — Probe each TLS version separately Repeat the handshake with TLS 1.0, 1.1, 1.2, and 1.3 explicitly requested. Tells us not just what was negotiated, but what the server still accepts when asked — the actual security exposure.
• Stage 5 — Validate the chain Walk the chain from leaf to root. Verify each issuer matches the next cert's subject. Confirm the final cert is in a trusted root store. Flag missing intermediates and incomplete chains.
• Stage 6 — Compose findings Days to expiry. Deprecated protocols still on. Chain integrity. Signature algorithm strength. Returned as structured fields so downstream tools can act on them.

A TLS certificate is an X.509 document with a fixed set of fields. Most of them follow the X.500 Distinguished Name standard from the 1980s, which is why the names look so dated. Two groups of fields — the identity (subject + issuer) and the metadata (validity, serial, fingerprints, keys):

• CN — Common Name Historically, the hostname the certificate is for. In 2026, CN is effectively legacy — modern browsers ignore it for hostname validation and use SAN entries instead. The CN is still populated for compatibility (the microsoft.com sample shows `CN=microsoft.com`) but it's not what determines validity.
• O — Organization Legal organization name on the certificate. For Domain Validation (DV) certs (Let's Encrypt and similar), this is usually blank. For Organization Validated (OV) and Extended Validation (EV) certs, the CA has verified the organization's legal existence. `O=Microsoft Corporation` in the sample is from an OV-grade cert.
• OU — Organizational Unit Subdivision within the organization — department, team, business unit. Optional and increasingly omitted; modern CAs discourage OU since it's hard to verify.
• C — Country Two-letter ISO 3166 country code. `US` for United States, `GB` for United Kingdom, etc.
• ST — State or Province Region within the country. Spelled out (`Washington`) or abbreviated (`WA`) — varies by CA convention.
• L — Locality City or town. `Redmond` in the Microsoft sample.
• SAN — Subject Alternative Name The list of hostnames the certificate is actually valid for. This is the field that matters in 2026 — browsers use it (not CN) to decide whether a cert is valid for a given hostname. A single cert can carry hundreds of SAN entries (1.1.1.1's Cloudflare cert covers ~150 of them). Wildcards like `*.example.com` live here.

• valid_from / valid_to When the certificate becomes valid and when it expires. The CA/Browser Forum caps maximum validity at 398 days (about 13 months) as of 2020, down from 2 years previously. Most modern certs are 90 days (Let's Encrypt default) or up to 398 days.
• Serial Number Unique identifier for the certificate within the issuing CA. Used in revocation lookups and audit trails. Hex-encoded, typically 16–20 bytes.
• Fingerprint (SHA-1) 20-byte SHA-1 hash of the entire certificate (DER-encoded). Historically used for cert pinning; SHA-1 itself is cryptographically broken since 2017, so the fingerprint is now legacy reference only — don't use it for new cert pinning.
• Fingerprint (SHA-256) 32-byte SHA-256 hash of the certificate. The current standard for pinning, comparison, and audit. When someone asks for a 'certificate fingerprint' today, this is what they mean.
• Public Key Algorithm RSA (most common, 2048-bit minimum, 4096 increasingly standard) or ECDSA (P-256 or P-384 — smaller, faster, mathematically equivalent strength). ECDSA is preferred for new deployments; RSA persists for compatibility with legacy clients.
• Signature Algorithm How the CA signed the certificate. Modern certs use SHA-256-with-RSA or SHA-256-with-ECDSA. SHA-1-based signatures were deprecated by browsers in 2017.

A TLS certificate isn't trusted directly — it's trusted because a Certificate Authority (CA) signed it, and that CA is trusted because another CA signed it, all the way up to a root CA pre-installed in your operating system or browser. The microsoft.com sample chain has four certificates; that's typical.

• Leaf certificate (end-entity) The certificate for the actual domain — microsoft.com in the sample. Signed by an intermediate CA. Has a short validity window (~13 months max) and exists in millions of variants — one per protected hostname.
• Intermediate CA A CA that signs leaf certs but is itself signed by another CA (usually a root, sometimes a higher-level intermediate). Intermediates exist so root CAs don't have to be online to sign every leaf — roots stay offline, intermediates do the day-to-day work. The Microsoft sample chain has two intermediates: `Microsoft TLS G2 RSA CA OCSP 16` (signs leafs) and `Microsoft TLS RSA Root G2` (signs the first intermediate).
• Root CA Self-signed (the issuer and subject are the same). Lives in your operating system's trust store and your browser's trust store, baked in by Apple, Microsoft, Mozilla, Google. The sample chain terminates at `DigiCert Global Root G2`, valid 2013–2038.
• Cross-signing When a CA's root signs another CA's intermediate — extending trust without minting new roots. The Microsoft example illustrates this: Microsoft runs its own intermediate hierarchy but cross-signs to DigiCert as the trust anchor. Same chain works for clients that trust either Microsoft or DigiCert at the root.
• The validation walk Your browser starts at the leaf, looks at its issuer, finds that issuer in the chain, validates its signature on the leaf. Then repeats — issuer's issuer, signature check — until it reaches a root that's in its trust store. Any break (missing intermediate, expired cert, signature mismatch) fails the entire chain.
• Common chain problems we catch Missing intermediate (server didn't send the intermediate cert in the handshake — Chrome works around it, Java doesn't). Wrong-order chain (rare but real). Expired intermediate (especially after a CA rotation — the leaf is fine, the intermediate isn't). Untrusted root (cert is self-signed or signed by a CA your client doesn't recognize).

TLS versions are a chronological story of attacks and patches. Six protocol versions have been deployed in production at some point. Today, only two of them should be enabled.

• SSL 2.0 (1995) — Deprecated, never enable Released by Netscape, full of fundamental flaws (no protection against truncation attacks, weak MAC construction, identical keys for encryption and authentication). Formally deprecated by IETF in 2011. Should never be enabled on any modern server.
• SSL 3.0 (1996) — Deprecated, killed by POODLE Significantly better than 2.0 but still vulnerable. POODLE attack (2014) demonstrated practical exploitation. Deprecated by IETF in 2015 (RFC 7568). Disable everywhere.
• TLS 1.0 (1999) — Deprecated by IETF in 2021 Internally known as SSL 3.1 — same wire format with security improvements. Vulnerable to BEAST (2011). Deprecated by IETF in RFC 8996 (March 2021). Disabled by browsers in 2020. Still enabled on some servers including the microsoft.com sample, which is a flag we surface.
• TLS 1.1 (2006) — Deprecated alongside TLS 1.0 Added explicit IV (fixing BEAST proactively) and support for stronger ciphers. Deprecated by the same RFC 8996 in 2021. Disable wherever you find it.
• TLS 1.2 (2008) — Current minimum baseline Authenticated encryption (AEAD ciphers), SHA-256 by default, support for elliptic curve algorithms. Still widely deployed and acceptable for most workloads. The minimum required by PCI DSS, HIPAA, and most enterprise compliance frameworks.
• TLS 1.3 (2018) — Current best Smaller, faster handshake (1 round-trip vs TLS 1.2's 2). Dropped support for everything legacy: RSA key exchange, CBC ciphers, SHA-1, MD5, static Diffie-Hellman. Only modern AEAD ciphers and ECDHE/DHE forward-secret key exchanges. If you can, support 1.3 alongside 1.2 and disable everything older.

The terms get used interchangeably and conflated constantly. Short version: every 'SSL certificate' issued today is actually a TLS certificate. The 'SSL' name persists from the 1990s when the protocol changed names; the certificates themselves are protocol-agnostic X.509 documents that work with either.

• SSL is the older name Secure Sockets Layer, invented by Netscape in 1994. Three versions deployed publicly: SSL 2.0 (1995), SSL 3.0 (1996), and the never-released SSL 1.0. All three SSL versions are deprecated and should never be enabled.
• TLS is the renamed successor Transport Layer Security, standardized by IETF starting in 1999. TLS 1.0 was effectively SSL 3.1 with security fixes — they share the wire format and design. The name change was partly technical (formalization through IETF) and partly political (Netscape was losing relevance). Every modern HTTPS connection uses TLS, not SSL.
• Why people still say 'SSL' Industry inertia, mostly. Marketing language stuck on 'SSL certificate' even after the underlying protocol was renamed. Product names like Let's Encrypt's predecessors still used 'SSL'. The OpenSSL library kept its name. End users learned 'SSL' first and never updated their vocabulary.
• What it means in practice today When someone says 'SSL certificate' in 2026, they mean a TLS certificate (an X.509 cert used by the TLS protocol). When someone says 'enable SSL on my site', they mean enable HTTPS / TLS. The terminology is sloppy but the meaning is usually clear from context.
• When the distinction actually matters When discussing protocol-specific vulnerabilities. POODLE specifically targets SSL 3.0. BEAST specifically targets TLS 1.0. The 'disable old protocols' recommendation usually means disabling SSL 2.0, SSL 3.0, TLS 1.0, AND TLS 1.1 — calling all four 'SSL' is technically wrong but operationally fine.

Every field returned on this page is available as JSON. Useful for expiry-monitoring crons, CI gates on production deploys, compliance audits, and SSL/TLS regression testing. Rate-limited per IP on the free tier.

// Single certificate (leaf)
const res = await fetch(
  'https://api.domainscan.in/v1/ssl?domain=microsoft.com'
);
const ssl = await res.json();

console.log(ssl.subject.CN);                   // 'microsoft.com'
console.log(ssl.issuer.CN);                    // 'Microsoft TLS G2 RSA CA OCSP 16'
console.log(ssl.valid_to);                     // expiry date
console.log(ssl.protocol['TLS 1.3'].status);   // 'Enabled'
console.log(ssl.protocol['TLS 1.0'].status);   // 'Enabled' — flag this

// Days until expiry — the metric to alert on
const daysToExpiry = Math.ceil(
  (new Date(ssl.valid_to) - Date.now()) / 86_400_000
);
if (daysToExpiry < 30) {
  console.warn(`Cert expires in ${daysToExpiry} days — renew now`);
}

// Full chain (separate endpoint)
const chain = await fetch(
  'https://api.domainscan.in/v1/ssl/chain?domain=microsoft.com'
).then(r => r.json());

console.log(`Chain length: ${chain.length}`);  // 4
for (const cert of chain) {
  console.log(cert.subject.CN, '←', cert.issuer.CN, cert.status);
}
// 'microsoft.com'              ← 'Microsoft TLS G2 RSA CA OCSP 16'  Valid
// 'Microsoft TLS G2 RSA CA...'  ← 'Microsoft TLS RSA Root G2'        Valid
// 'Microsoft TLS RSA Root G2'   ← 'DigiCert Global Root G2'          Valid
// 'DigiCert Global Root G2'    ← 'DigiCert Global Root G2' (self)    Valid

// GET /v1/ssl?domain=<host>  — leaf certificate only
{
  "subject": {
    "CN": "hostname",
    "O":  "organization (may be empty for DV certs)",
    "OU": "organizational unit (optional)",
    "C":  "ISO 3166 country code",
    "ST": "state or province",
    "L":  "locality / city",
    "SAN": ["hostname1", "*.wildcard.example"]
  },
  "issuer": {
    "CN": "CA name",
    "O":  "CA organization",
    "C":  "..."
  },
  "valid_from":     "ISO 8601",
  "valid_to":       "ISO 8601",
  "serialNumber":   "hex string",
  "fingerprint":    "SHA-1 colon-separated hex",
  "fingerprint256": "SHA-256 colon-separated hex",

  "protocol": {
    "TLS 1.3": { "status": "Enabled | Disabled", "desc": "TLS 1.3 (Released in 2018)" },
    "TLS 1.2": { "status": "Enabled | Disabled", "desc": "TLS 1.2 (Released in 2008)" },
    "TLS 1.1": { "status": "Enabled | Disabled", "desc": "TLS 1.1 (Released in 2006, Deprecated)" },
    "TLS 1.0": { "status": "Enabled | Disabled", "desc": "TLS 1.0 (Released in 1999, Deprecated)" }
  }
}

// GET /v1/ssl/chain?domain=<host>  — full chain
[
  {
    "subject":        { /* DN fields */ },
    "issuer":         { /* DN fields */ },
    "valid_from":     "ISO 8601",
    "valid_to":       "ISO 8601",
    "serialNumber":   "hex string",
    "fingerprint256": "SHA-256 hex",
    "status":         "Valid | Expired | Untrusted | Revoked"
  }
  /* index 0 = leaf, last index = root (self-signed) */
]

Six patterns we see most often:

• What's the difference between SSL and TLS? SSL (Secure Sockets Layer) is the older name; TLS (Transport Layer Security) is the renamed successor. SSL 2.0 and 3.0 are obsolete; TLS 1.0 through 1.3 are versions of the modern protocol. When someone says 'SSL certificate' in 2026, they almost always mean a TLS certificate — the certs themselves work with both, and the terminology is sloppy but understood.
• How often should I check my SSL certificate? For production sites: daily, automated. Cert expiry is the most common preventable outage cause in operations. For one-off checks during deployment or migration: anytime config changes. For audit/compliance purposes: at least quarterly with retained evidence.
• What is a chain of trust? The cryptographic path from your site's certificate (the 'leaf') up through one or more intermediate Certificate Authorities to a 'root' CA that's pre-installed and trusted in operating systems and browsers. Each cert in the chain is signed by the next one up. If any link is missing, expired, or untrusted, the entire chain fails and the browser shows a warning.
• Why is TLS 1.0 still enabled on my server? Usually because the default config of older web servers (Apache, nginx, IIS) included it, and nobody explicitly disabled it during the original setup. The fix is a one-line config change. Modern installations should set the minimum TLS version to 1.2 (or 1.3 if your client base supports it). Major browsers all dropped TLS 1.0 support in 2020 — you're not breaking real users.
• What's an SSL grade and how is it calculated? Most often refers to SSL Labs' A+ through F grading scale, which weighs protocol versions supported, cipher suite strength, key strength, certificate chain integrity, vulnerabilities (POODLE, BEAST, Heartbleed, etc.), and HSTS configuration. This tool doesn't currently produce a graded score — it gives you the raw structured data underlying any such grade so you can build your own criteria.
• What's a wildcard certificate? A cert valid for any single-level subdomain of a domain — `*.example.com` covers `www.example.com`, `api.example.com`, `app.example.com`, but not `deep.api.example.com` (that needs a separate cert or a more specific wildcard like `*.api.example.com`). Convenient for managing many subdomains; the tradeoff is that a single private-key compromise puts every subdomain at risk.
• How do I get a free SSL certificate? Let's Encrypt is the dominant free CA — issues DV (Domain Validated) certs at no cost, valid for 90 days, with automated renewal via the ACME protocol. Most modern hosting platforms and web servers integrate Let's Encrypt natively. ZeroSSL, Buypass, and Cloudflare also issue free certs. For OV or EV certs (with verified organization identity), expect to pay a CA fee.
• What happens when my SSL certificate expires? Browsers immediately show a full-page warning to users and refuse to load the site without manual override. API clients (mobile apps, integrations, curl, Java applications) get TLS handshake failures and reject the connection entirely. There's no grace period and no soft failure — the day after expiry, your site is effectively down for anyone using a reasonably modern client.