Security

SSL Checker

Inspect certificate chain, expiry and algorithm for any site.

Hostname host or host:port (default 443)

Try: github.com cloudflare.com example.com badssl.com

About this tool

SSL Checker opens a real TLS connection to your host, captures the certificate chain the server presents, and reports everything that matters: subject, issuer, validity dates, the full intermediate chain up to the trust anchor, signature algorithm, public key size, supported TLS versions and cipher suites, Subject Alternative Names, and OCSP stapling status. The check happens server-side from our Frankfurt host so you see exactly what a remote visitor sees — not what your browser cached.

A clean certificate is not just "the green padlock". We validate hostname matching against SANs (the legacy CN field is informational only, per RFC 6125), check that each link in the chain is signed by the next, verify that intermediates are presented in the right order (a common deploy mistake), confirm the leaf has not expired and is not yet valid, and warn if the leaf uses a weak signature (SHA-1) or undersized key (RSA < 2048 bits). All this in one HTTPS handshake.

When to use this tool

Pre-deploy verification. After provisioning Let's Encrypt or buying a commercial cert, confirm the chain is complete before pointing real users at it.
Expiration monitoring. Spot certs that will expire in the next 7/14/30 days and renew before alarms fire.
Mixed-content debugging. Find subdomains that present a different (or self-signed) cert from the main site.
Migration sanity checks. After moving to a new CDN or load balancer, verify the new cert and chain are what you expect.

What "chain incomplete" actually means

Browsers and OS trust stores ship a few hundred root CAs. Your leaf certificate is signed by an intermediate, which is signed by another intermediate or directly by a root. The web server must send the leaf + every intermediate up to (but not including) the root — Firefox and Chrome will try to fetch missing intermediates from the AIA extension, but iOS, older Android, and most non-browser TLS clients will reject the handshake. Our chain inspector tells you exactly which link is missing, so you can paste the right intermediate into your server config.

Frequently asked questions

My browser shows the padlock but your tool says "chain incomplete" — who is right?

Both. Modern desktop browsers patch incomplete chains by fetching missing intermediates over the AIA extension or from their own caches — the user sees a working padlock. But iOS Safari, many Android apps, curl, OpenSSL clients, and non-browser TLS libraries do not do this. If our tool says "incomplete" your site will fail on a non-trivial fraction of clients; fix it by serving the full chain from the server.

What is OCSP stapling?

A way for the server to attach a recent CA-signed proof-of-validity to the certificate during the TLS handshake — so the browser does not have to call out to the CA's OCSP responder on every connect. Stapling makes page loads faster and protects user privacy (the CA never learns which sites the user is visiting). Most modern web servers (nginx, Apache 2.4, Caddy) support it; many turn it on by default.

How often should I check?

Once a week is plenty for production. Let's Encrypt certs renew every 60–90 days, commercial certs every 12 months; either way an unnoticed expiry is the most common SSL failure mode. We cache results for 10 minutes so a quick re-check after a deploy gives immediate feedback. Pair this with an automated monitor (Uptime Kuma, StatusCake) for proactive alerts.

Why does the tool not validate against my private CA?

We use the standard public CA trust bundle (Mozilla's, which most operating systems also use). Private CAs — internal corporate roots, ACME-CA on a homelab — are not in any public trust store, so the chain validation will (correctly) flag them as untrusted. The certificate details (subject, dates, key size) are still reported; only the trust-anchor check fails.