SSL Checker
Inspect certificate chain, expiry and algorithm for any site.
- Certificate is valid for this host and not expired.
- cloudflare.com
- ns.cloudflare.com
- *.ns.cloudflare.com
- *.secondary.cloudflare.com
- secondary.cloudflare.com
What does each field mean?
Field reference
Subject
The Subject field identifies the certificate holder. Modern certificates rely on the CN (Common Name) plus Subject Alternative Names. Organization (O), Organizational Unit (OU), and Locality (L) are present for EV/OV certs and absent for plain DV (free) certs like Let's Encrypt.
Issuer
Identifies the CA that vouched for the subject. Browsers ship a list of trusted root CAs; certificates signed by an untrusted issuer (or self-signed) trigger NET::ERR_CERT_AUTHORITY_INVALID. Common public CAs: Let's Encrypt, DigiCert, Sectigo, GlobalSign, GoDaddy.
Subject Alt Names (SAN)
A single certificate can cover multiple hostnames via the SAN extension — typical for wildcard (<code>*.example.com</code>) or multi-domain (SAN) certs. Browsers ignore the Common Name and match only against SAN entries since 2017. If your hostname is not listed here, the certificate is invalid for that host.
Chain depth
A trust chain starts with the server's leaf cert, passes through one or more intermediate CA certs, and ends at a root CA in the browser's trust store. Depth 2 (leaf + 1 intermediate) is typical. Misconfigured servers often forget to send intermediates — clients then see "incomplete chain" errors.
Signature algorithm
Describes how the CA signed the cert. <code>sha256WithRSAEncryption</code> (RSA + SHA-256) is the safe default. <code>ecdsa-with-SHA256</code> uses elliptic curves — smaller keys, same security. <code>sha1WithRSAEncryption</code> has been broken since 2017 and is rejected by all major browsers.
Public key
The public half of the keypair. RSA 2048 bits is the practical minimum today; 3072+ for long-lived keys. EC P-256 is shorter (~256-bit equivalent strength) and faster. Anything below RSA 2048 or older than P-256 should be replaced.
Negotiated cipher
Describes encryption used for the actual data: key exchange (ECDHE), cipher (AES_256_GCM, CHACHA20_POLY1305), MAC (SHA384). Forward-secret cipher suites (ECDHE-*) are required by most security standards. CBC-based or RC4 suites are obsolete.
Hostname match
Even a perfectly valid certificate is rejected if the requested hostname is not in the SAN list. Wildcards match exactly one DNS label: <code>*.example.com</code> covers <code>www.example.com</code> but NOT <code>a.b.example.com</code> or the bare <code>example.com</code>.
Self-signed
A self-signed cert has the same Subject and Issuer. Browsers do not trust it by default — you would see "NET::ERR_CERT_AUTHORITY_INVALID". Fine for internal/staging environments where you control both server and client. For production, use Let's Encrypt (free) or a public CA.
Valid to (expiry)
Browsers reject expired certificates outright. Public-CA certs typically last 90–397 days. Set up auto-renewal: ACME / Let's Encrypt at 60 days remaining, commercial CAs at 30 days. Watch for the gradual industry shift to 90-day mandatory lifetimes by 2027.
Fully valid
All baseline checks passed: trust chain anchors at a browser-trusted root, hostname matches the SAN, the cert is within its validity window, and the signature algorithm is acceptable. This is the green-padlock state browsers display.
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 theAIA 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?
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.