SSL Certificate Checker

A TLS handshake does not just confirm that a certificate exists - it has to confirm a chain of trust from the certificate the server presents up to a root CA the client already trusts. The server sends its own (leaf) certificate plus, ideally, any intermediate certificates needed to connect that leaf back to a root. Clients trust roots, not intermediates by name, and need those links to walk there.

A chain that stops one certificate short of a trusted root is the single most common real-world TLS misconfiguration: browsers that cache the missing intermediate from a previous visit connect fine, while clients without that cache fail outright. A site can "work" in one browser and throw a trust error in curl at the same time.

Each certificate in the chain carries its own validity window (RFC 5280 defines the X.509 fields: notBefore, notAfter, subject, issuer, subjectAltName), independently - a valid leaf chained to an expired intermediate is still a broken chain.

• Leaf (server) certificate → intermediate CA certificate(s) → root CA - the root itself is never sent by the server
• Subject Alternative Name (SAN), not the Common Name field, is what modern browsers actually check for hostname match (CN matching was deprecated by RFC 2818 back in 2000, and Chrome stopped falling back to it in 2017)
• A wildcard SAN like *.example.com covers one label of subdomain (mail.example.com) but not a second level (mail.uk.example.com)
• Certificate Transparency (RFC 6962) requires publicly trusted CAs to log every issued certificate to public, append-only logs - a certificate a browser cannot find in any CT log is treated as suspect

The result is organized around the actual handshake performed against port 443, not a cached grade. `certificateChain` lists every certificate returned, from the leaf outward, each with its `subject`, `issuer`, `validFrom`/`validTo` dates, `fingerprint`, key algorithm and size, and OCSP responder URLs. `chainInfo.complete` reports whether the last certificate is self-signed by a root or stops short (incomplete - the failure above).

`connectionInfo` reports what was actually negotiated: TLS `protocol` version, `cipher` name, and a breakdown (`cipherAnalysis`) of key exchange, authentication, encryption, and hash algorithm, including forward secrecy. Any deprecated protocol, weak cipher, or missing forward secrecy shows up in `connectionInfo.vulnerabilities`.

`securityHeaders` reports whether the server sent Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy, with the HSTS `max-age`, `includeSubDomains`, and `preload` flags parsed out. `caaRecords` shows which CAs the domain's DNS permits to issue for it. `ocspStatus` reports whether OCSP responder URLs answered, and `certificateTransparency` whether the certificate's SCTs were found in public CT logs.

A certificate is valid only inside the window between its `notBefore` and `notAfter` timestamps (RFC 5280), with no browser grace period - one expired a minute ago produces the same hard trust error as one expired a year ago. Public CAs cannot issue certificates with lifetimes above the CA/Browser Forum ceiling, which root programs enforce by refusing longer-lived certificates. That ceiling has been ratcheting down - 398 days for years, then 200 days from March 2026 under ballot SC-081, on a path toward 47 days by 2029. This is why automated renewal (ACME, RFC 8555, the protocol behind Let's Encrypt) replaced manual yearly renewal: a shrinking maximum lifetime makes any manual process an easy-to-miss chore.

Chain expiry compounds this: an intermediate CA certificate can expire while the leaf it signed is still within its own window, and vice versa. Rotating an intermediate can silently break sites which cached the old one - a renewal commonly swaps in a new leaf certificate correctly while leaving a mismatched intermediate bundle configured on the server.

TLS versions are not interchangeable: SSLv2 and SSLv3 are broken protocols and should never be enabled. TLS 1.0 and 1.1 were formally deprecated by RFC 8996 in March 2021 and are blocked outright by current major browsers. TLS 1.2 remains safe with modern cipher suites; TLS 1.3 (RFC 8446) simplifies the handshake, drops static RSA key exchange and CBC-mode ciphers entirely, and is the current baseline.

A cipher suite bundles four choices: key exchange, authentication (how the server proves its identity), bulk encryption, and the hash/MAC used for integrity. ECDHE and DHE key exchanges are ephemeral - a fresh key is generated per session and discarded afterward, which is what forward secrecy means in practice: stealing the server's long-term private key later still does not decrypt traffic recorded today. Static RSA key exchange has no such property; a single compromised key makes every past session recorded under it readable. AEAD modes (AES-GCM, ChaCha20-Poly1305) combine encryption and integrity checking in one step and have largely replaced CBC-mode ciphers, which carry padding-oracle risk (the BEAST and Lucky 13 attack family) on older TLS versions.

A valid certificate only secures the transport; the response headers determine how much of that protection reaches the browser's handling of the page. HTTP Strict Transport Security (RFC 6797) tells the browser to refuse plain-HTTP connections for the `max-age` duration, closing the window where a first visit over HTTP could be intercepted before the redirect to HTTPS. `includeSubDomains` extends that to every subdomain, and `preload` bakes the domain into browsers' built-in HSTS list - difficult to reverse once set.

Content-Security-Policy restricts which sources a page may load scripts and other resources from - the primary defense against cross-site scripting exfiltrating data even after an attacker gets a script tag onto the page. X-Content-Type-Options: nosniff stops browsers guessing a different MIME type than declared. Referrer-Policy controls how much of the current URL leaks to third parties when a user follows a link out.

None of these headers affect the TLS handshake itself - a server can have a pristine certificate chain and ship none of them, which is why they appear as a separate section rather than folded into certificate validity.