SSL Certificate Checker

Check the TLS/SSL certificate of any host: what it is valid for, who issued it, when it expires, whether the chain is trusted, and which protocol was negotiated. This is exactly the information your browser (and any client) uses to decide whether an HTTPS connection is safe.

What this checks

When you connect over https://, the server presents a certificate. The client verifies three things before trusting it: that the certificate chains up to a trusted root, that it is still within its validity period, and that the hostname you requested is listed in its Subject Alternative Names. This tool performs the same checks and shows you the raw material: the subject, the issuer, the SAN list, the validity dates, the public-key type, the SHA-256 fingerprint and the full certificate chain sent by the server.

We also report the negotiated protocol (TLS 1.2 or TLS 1.3) and cipher suite. Because we open the TLS handshake without enforcing trust, you still get useful details even when the certificate is expired, self-signed or otherwise broken — precisely the cases where you need to look closely.

Reading the fields

• Subject / CN — the name the certificate was issued for. A value like *.example.com is a wildcard covering one label of subdomains.
• Issuer — the certificate authority (CA) that signed it. The browser trusts the chain up to a built-in root, not the leaf directly.
• Valid from / to — the validity window. Certificates are usually valid for 90 days now, so expiry is a routine risk.
• Days remaining — how long until it expires. Anything under 14 days deserves attention.
• SAN — Subject Alternative Names: the complete list of hostnames/IPs the certificate is valid for. Modern browsers ignore the old CN field when SAN is present.
• Chain — the leaf plus any intermediate certificates the server sent. A missing intermediate is a classic cause of trust failures on some clients.

Common certificate errors and how to fix them

The validity period has passed or has not started. Check the server's clock first — a badly skewed clock can make a valid certificate look expired — then confirm the certificate really is outside its window using the dates above. On the server, renew the certificate (certbot renew, your provider's renewal, or your ACME client) and reload the web server. The most common cause by far is simply a renewal that silently failed, so set up a renewal reminder or monitoring.

The name you requested is not in the certificate's SAN list. This happens when the certificate was issued for example.com but you visit www.example.com (or a subdomain), when a wildcard does not cover the depth you need (a wildcard matches only one label), or when the wrong certificate is selected on a server hosting several sites. Fix it by issuing a certificate that includes the exact name (add the subdomain or use a broader SAN), or by correcting the hostname/SNI configuration.

Here the protocol negotiation never completed, so no certificate could be validated. Typical triggers: you pointed https:// at a plain-HTTP port (or http:// at a TLS port), the server speaks a TLS version the client rejects, or a proxy/antivirus is rewriting traffic. Confirm the port (443 for HTTPS), check that the server actually has TLS enabled on that port, and remove middleboxes that inspect encrypted traffic.

The chain does not lead to a trusted root: it may be self-signed, issued by an unknown CA, or missing an intermediate certificate. If the leaf is fine but clients still complain, install the full chain (leaf + intermediates) on the server. Self-signed certificates are expected only internally and should not be used on public sites.

If something is wrong

1. Expired? Renew and reload. Confirm with this tool that the new Valid to date is in the future, then reload.
2. Wrong name? Re-issue with the exact host in the SAN list; remember wildcards cover a single label only.
3. Untrusted chain? Serve the intermediate certificates too. Many servers ship the leaf only.
4. Protocol error? Make sure the port serves TLS and that the client supports the offered versions (TLS 1.2/1.3).

Privacy and limits

We connect to the host, complete a TLS handshake to read the certificate, and then close the connection. We do not follow further links or send any data beyond the handshake. Only public IP addresses are allowed (private, loopback and reserved ranges are blocked). Requests are rate-limited per IP address and results are cached for under a minute.