First CH Apps / SSL/TLS Certificate Checker
Enter a hostname and our server connects to port 443 and reads the certificate that host is serving right now. You get the expiry date and days remaining, the issuer, the names it covers (SAN) and the intermediate chain — with a warning once fewer than 30 days remain.
This app looks at the certificate and the TLS connection only. HTTP response headers such as HSTS are graded by the Security Header Grader, and page content by the Meta Tag & SEO Basics Check.
| Expiry | The end date and the days remaining. Under 30 days is a warning; an expired certificate needs attention. |
|---|---|
| Hostname match | Whether the hostname you entered appears in the Subject Alternative Name. A wildcard matches exactly one left-most label (RFC 6125). |
| Issuer and chain | Every certificate the server sends is read in order to spot a missing intermediate, a broken order, or an intermediate that is itself close to expiry. |
| Key and signature | Key type and size (RSA below 2048 bit needs attention) and the signature algorithm (SHA-1 and MD5 need attention). |
| TLS 1.3 support | One extra connection offers TLS 1.3 and records which version the server picks. |
This tool reads the certificate. It does not verify signatures, check revocation (CRL / OCSP) or compare against a trust store, so the final word on “does the browser trust it” belongs to the browser.
The handshake is capped at TLS 1.2 so the certificate is readable. Servers that accept only TLS 1.3 fall back to the CT log view.
Hosts our runtime cannot reach over raw TCP — Cloudflare-fronted sites among them — also fall back to the CT log view. That is a limitation of where this app runs.
If several servers serve different certificates, you see the one from whichever machine answered. Behind a load balancer the result can change between runs.
The key exchange is never completed: we drop the connection as soon as the certificate arrives, and no application data is ever sent to the target site.
Sent: only the hostname you type. Our server (Cloudflare Workers) sends a TLS ClientHello — including that hostname as SNI — to port 443. No cookies, credentials or HTTP request are sent.
Stored: nothing. The check lives entirely inside one request and writes neither the hostname nor the result to any database (no KV, no D1). It leaves memory when the request ends.
Returned: the fields read from the certificate (issuer, validity, SAN, key, signature, fingerprint) and the verdict. No page content is fetched or re-served.
External lookups: Cloudflare DNS over HTTPS resolves the hostname. Only when the direct connection fails do we query the public CT log API (crt.sh) for that hostname.
Note: hostnames pointing at internal networks, localhost or private IPs are rejected, judged on the resolved IP address.
POST /ssl/api/inspect with JSON ({"host": "example.com"}) or a form body and you get the same result back as JSON.