🔒 SSL Checker ☆

Overview

SSL Checker inspects the TLS certificate behind any HTTPS site. Enter a domain and the tool performs a real handshake from a 0Appz server: you get the certificate subject and issuer, the exact validity window, the days remaining before expiry (highlighted when under 30 days), the full Subject Alternative Names list, the serial number and signature algorithm, plus the negotiated TLS version and cipher suite. A second verified connection tells you whether browsers would trust the certificate, so self-signed, expired, hostname-mismatched and incomplete-chain certificates are flagged clearly instead of failing silently. Ideal for confirming renewals went through, debugging "not secure" warnings, auditing vendor sites and checking certificates before a launch.

What the checker verifies

The tool opens a real TLS connection from a 0Appz server and reports exactly what the handshake returns: subject and issuer, the full validity window with days remaining, every Subject Alternative Name, the serial number and signature algorithm, plus the negotiated protocol version and cipher suite. A second verified connection tests the chain the way browsers do, so self-signed, expired, wrong-hostname and incomplete-chain certificates are explicitly flagged rather than silently accepted.

Capabilities and constraints

Property	SSL checker behavior
Input	Any hostname serving HTTPS
Certificate data	Subject, issuer, validity, days left, SANs, serial, signature algorithm
Connection data	TLS version and cipher suite negotiated
Trust check	Second verified connection simulates browser validation
Common failures	Expired, self-signed, hostname mismatch, incomplete chain
Cost	Free, no account, unlimited checks

Privacy: the check runs from our server, not yours

The handshake is performed server-side because browsers do not expose certificate chains to JavaScript. That means 0Appz connects to the hostname you enter; the domain you check is not stored or logged as a user record, and no data about your own connection is shared with the target.

What to watch for

• Days remaining under 30 should trigger an immediate renewal.
• Missing SANs cause browser warnings for alternative hostnames.
• An incomplete chain breaks some mobile clients even when browsers accept it.
• Old TLS versions or weak ciphers should be disabled in server config.
• After renewing, re-run the check to confirm the new certificate is served.

Related: browse the developer tools for DNS, headers, IP and whois checks.

Certificate chains, expiry and trust

An HTTPS connection depends on a chain of trust, not on a single certificate. The server presents its leaf certificate plus any intermediate certificates, and the browser validates the chain up to a root it already trusts. A missing intermediate is the most common misconfiguration: some browsers cache intermediates from earlier visits and appear fine, while fresh visitors and mobile clients fail with a vague error. The leaf certificate must cover the exact hostname, through the common name in older certificates or a subject alternative name entry in modern ones, and a wildcard covers only one level, so example.com and app.example.com need separate entries. Expiry is the next thing to watch: certificates are now issued for 90 days or less by many authorities, which makes automated renewal essential rather than optional. Revocation is checked through OCSP or CRLs, and stapling lets the server attach the OCSP response to the handshake. Protocol and cipher support matter as well: TLS 1.2 is the practical minimum and TLS 1.3 is preferred, while anything below 1.2 should be disabled. Two related checks complete the picture: HSTS tells browsers to refuse plain HTTP in future, and mixed content, an HTTPS page loading images or scripts over HTTP, silently weakens the whole connection. The check runs from your browser and stores nothing.