Why Your SSL Checker Never Actually Connects to the Server — How Certificate Transparency Logs Work

Guide · Last verified Aug 28, 2026

If you've ever used a browser-based tool to check "when does this domain's SSL certificate expire?", you may have wondered: can browser JavaScript really connect to an arbitrary third-party server and inspect its certificate? The answer is no. This guide explains how browser-based SSL checkers actually work, and the fundamental limitation baked into that approach.

1. A browser can't open a TLS handshake to an arbitrary server

Run openssl s_client -connect example.com:443 or curl -vI https://example.com from a server terminal, and you'll perform a real TLS handshake with the target server and pull its certificate on the spot. But JavaScript running in a browser has no low-level TCP socket API to do this at all. That's not a bug — it's a deliberate security design. If a web page could open raw sockets to arbitrary servers on arbitrary ports, it would open the door to serious abuse (internal network scanning, protocol smuggling, and more). So any "SSL checker" tool that runs in the browser has to get certificate data some other way.

2. The alternative: querying Certificate Transparency (CT) logs

Certificate Transparency (CT), a scheme Google began pushing around 2013, requires every certificate issued by a public Certificate Authority (CA) to be submitted to a public, verifiable, append-only log. Today, essentially every major browser refuses to trust a certificate that isn't registered in a CT log, which makes the requirement effectively mandatory. crt.sh (operated by Sectigo) indexes the entire CT log and makes it searchable. Enter a domain name, and you can pull up every certificate ever issued for that domain — without ever connecting to the target server itself.

3. What this tool actually does

Looking at the source code, the SSL checker calls crt.sh's JSON API in the form fetch('https://crt.sh/?q=DOMAIN&output=json'). Instead of performing a live handshake with the server, it pulls the most recent certificate record from the CT log — expiry date, issuer, and list of SAN domains. Worth noting: the date strings crt.sh returns carry no timezone suffix, but they're actually UTC, so the tool explicitly converts them to UTC rather than letting the browser misinterpret them as local time.

4. The limits of a CT-log-based check

A CT log only shows issuance history — it makes no guarantee that it matches what the server is currently presenting. For example, if a server misconfiguration means it's still serving an old, expired certificate, or it's loading the wrong one out of several available, a CT log lookup alone can't tell you. Likewise, everything a live handshake would reveal — which TLS protocol versions are supported, the cipher suite actually negotiated, chain-validation results from the client's point of view, or whether the certificate has been revoked (via OCSP/CRL) — is completely invisible to a CT log query. The two methods are complementary, not interchangeable.

5. Which to use, and when

• Issuance history and auditing (has a suspicious certificate ever been issued for this domain? did a private CA misissue something?) is exactly what CT-log-based lookups are good for. Security researchers actually use CT logs this way in practice.
• To verify that the server's current configuration is correct right now, you need a tool that performs a real handshake (e.g. SSL Labs' server test, which runs server-side).
• This isn't a flaw specific to this one tool — it's a structural limitation of what's achievable with browser JavaScript alone.

FAQ