Check certificate validity and expiry for any domain
SSL Checker fetches the SSL/TLS certificate presented by any public HTTPS host and shows you the details that matter: the common name and Subject Alternative Names (SANs), the issuing Certificate Authority, the validity window (Not Before and Not After dates), the days remaining before expiry, the signature algorithm, and the full chain up to the root. Enter a domain such as example.com and it connects on port 443 to read the live leaf certificate exactly as a browser would.
It is built for site owners, sysadmins, and developers who need to confirm a certificate is valid, covers the right hostnames, is not expired or self-signed, and chains correctly to a trusted root before pointing users or an API at it.
When you submit a hostname, the tool performs a TLS handshake against the host on the chosen port and captures the X.509 certificate the server returns. From that certificate it parses the standard fields: the Subject (who the cert identifies), the Issuer (which CA signed it), the Subject Alternative Names extension (all hostnames the cert is valid for), the validity period, and the public key and signature algorithm (for example RSA 2048-bit or ECDSA P-256 signed with SHA-256).
Two things are validated beyond simply reading fields. First, hostname matching: modern clients ignore the legacy Common Name and require the requested host to appear in the SAN list, so a cert for example.com will not cover www.example.com unless both are listed. Second, chain of trust: the leaf certificate must be signed by an intermediate, which is in turn signed by a root CA in the trust store. A missing intermediate is a common misconfiguration that works in some browsers (which cache intermediates) but fails in others and in many API clients.
Expiry is computed as the difference between the Not After date and now. Because public CAs now issue certificates with short lifetimes (many are capped at around 398 days, with the industry moving shorter), monitoring days-remaining is the practical way to avoid an outage from a lapsed certificate.
The hostname you entered is not listed in the certificate's Subject Alternative Names. A cert issued for example.com does not automatically cover www.example.com or subdomains unless those names (or a wildcard like *.example.com) appear in the SAN extension.
It means the server sent the leaf certificate but omitted one or more intermediate certificates needed to link it to a trusted root. Some browsers hide this by caching intermediates, but strict clients and many API libraries will reject the connection. Fix it by installing the full chain on the server.
Watch the days-remaining value and renew well before it reaches zero. A common practice is to renew or confirm automation at 30 days out; if you use ACME clients like Certbot, renewal is typically automatic at the 30-day mark.
Yes. Set a custom port for services that do not run HTTPS on 443, such as 8443 for alternate web endpoints or 465 for SMTPS. The tool performs the TLS handshake on whatever port you specify.
It can read and display a self-signed certificate's details, but it will flag it as untrusted because it does not chain to a recognized public CA. The tool only reaches hosts that are publicly resolvable and reachable, so it cannot inspect servers on a private network.
Yes, it is completely free with no sign-up. You submit only a hostname and optional port; the tool reads the public certificate that any client would see during a normal TLS handshake and does not store your queries or the certificate contents.
A certificate can be within its validity window yet still trigger warnings for other reasons, such as a weak signature algorithm (for example SHA-1), a small key, a hostname mismatch, or a missing intermediate. Review each status flag individually rather than relying on the expiry date alone.