SSL Certificate Checker

Detailed SSL/TLS certificate analysis: validity, chain, SAN, key, signature.

SSL Certificate Checker

Check a website's SSL certificate the way a browser validates it: expiry date and days left, the domains it covers (SAN), issuer, key type and size, signature algorithm and the chain the server sends. If the certificate has expired, was issued for another name or the server omits the intermediate certificate, the check returns a connection error.

Expiry date and days left, with a 30-day warning

Issuer, Common Name and every domain in the SAN

Certificate chain from the server with expiry dates

Key type and size, signature algorithm

How to Use

Enter a domain or page URL; add a port after a colon if needed
Check the expiry date and the domains in the SAN
If you get an error instead of a report, find the cause in the table below

FAQ

Enter the domain in the field above, for example example.com. The tool connects over HTTPS and shows the expiry date, issuer, the domains in the certificate and the chain. Add a non-standard port after a colon: example.com:8443.

Most often the server does not send the intermediate certificate. Some browsers fetch it on their own; this check, search bots and many API clients do not. Serve the full chain (fullchain.pem in nginx). The other common cause is a certificate that does not cover www or whichever name you checked.

The end date and the number of days left are at the top of the report. Under 30 days, the banner turns yellow. Let's Encrypt certificates last 90 days and should renew automatically.

No. It checks the certificate itself: validity, names, issuer, key and chain. TLS versions, cipher suites, revocation and HSTS are not analysed here.

No. *.example.com covers www.example.com and other first-level subdomains, but not example.com itself. That is why both names usually appear in the SAN; check the domain list in the report.

What the SSL certificate check shows

The tool connects to the site over HTTPS (port 443, or the port in the address, such as example.com:8443), sends the domain name via SNI and fetches the certificate the same way a browser does. The report covers:

Validity: start and end dates and the days left. Under 30 days, the banner turns yellow.
Common Name and Subject Alternative Names (SAN): the domains the certificate was issued for. Browsers check the SAN list.
Issuer: the certificate authority, such as Let's Encrypt, Sectigo, DigiCert or Google Trust Services.
Key and signature: key type (RSA or ECDSA), key size in bits and signature algorithm. RSA keys under 2048 bits are flagged as weak.
Certificate chain as sent by the server, with the expiry of each link.
Serial number, certificate version and connection time.

Why the check returned a connection error

The certificate is validated with the same rules a browser uses. If validation fails, the connection is not established and you get an error instead of a report. The usual causes:

Cause	How to confirm	Fix
Certificate expired	The browser says the certificate has expired	Renew it. With Let's Encrypt, make sure auto-renewal works (`certbot renew --dry-run`)
Name mismatch	The site loads on `www` but the certificate covers only the bare domain, or the other way round	Issue a certificate with both names in the SAN
Missing intermediate certificate	`openssl s_client` (below) shows a single certificate	Serve the full chain: in nginx use `fullchain.pem`, not `cert.pem`
Untrusted certificate authority	Issued by an internal or unknown CA	Replace it with a certificate from a public CA
HTTPS not set up	Port 443 is closed, as the port checker will show	Enable HTTPS on the server or in your hosting panel

An incomplete chain is the sneaky one. Some browsers fetch the missing intermediate on their own, so the site works for you while some visitors, search bots and API clients get an error. This check never fetches anything extra, so it exposes the problem.

A self-signed certificate is accepted and reported. You can spot it easily: the issuer is the domain itself and the chain has a single link. Browsers warn about it, so it is not suitable for a public website.

How a certificate chain works

The chain starts with the site's certificate, continues with one or more intermediates and ends with a root that is already in the browser's or operating system's trust store. The server must send its own certificate and every intermediate; the root does not need to be sent. To inspect the chain from the command line:

openssl s_client -connect example.com:443 -servername example.com -showcerts

How long an SSL certificate lasts

The maximum lifetime of public certificates keeps shrinking. It was 398 days until March 2026 and is 200 days from 15 March 2026; under the CA/Browser Forum schedule it drops to 100 days in 2027 and 47 days in 2029. Let's Encrypt certificates last 90 days. The takeaway: renewal must be automated and expiry monitored. The 30-day warning in the report exists for exactly that reason.

www, subdomains and wildcards

The certificate must cover every hostname the site answers on. A wildcard *.example.com covers www.example.com and shop.example.com, but not example.com itself and not a deeper level such as a.b.example.com. That is why the SAN list usually contains both example.com and *.example.com.

Key and signature algorithm

RSA 2048 is the normal minimum; ECDSA (usually P-256) is the modern choice with a smaller key and equivalent strength. A sha256WithRSAEncryption or ecdsa-with-SHA256 signature is standard. Browsers stopped accepting SHA-1 years ago.

What this check does not cover

TLS versions and cipher suites, vulnerabilities and revocation (OCSP, CRL).
HSTS and other headers: use the security headers check, or the website security scanner for a broader review.
Whether http:// redirects to https://: the redirect checker shows that.

HTTPS is a lightweight ranking signal for Google, but an expired certificate hurts traffic immediately: browsers show a full-page warning and visitors leave.