Tool · TLS

The certificate, not the browser lock

The lock can be green and the cert still wrong: bad name, broken chain, three days left. We open TLS and read that without asking Chrome.

The first check is free. To run again, a work email — not Gmail or a personal Outlook.

Example: www.example.com or https://www.example.com

What usually breaks

Let’s Encrypt cron left disabled. A wildcard that does not cover www. A missing intermediate because someone pasted only the leaf into nginx. Common.

HSTS is separate: the cert can be fine and the browser still will not force HTTPS. We read the header on the page, on top of the handshake.

What we read

Trust chain
Does the server send a chain a known CA accepts? We report the authorization error.
Expiry
Under 14 days we warn. Expired is red. It is just validTo.
Name (SAN / CN)
www.example.com is not example.com. *.example.com is not a free-for-all on deeper labels.
Protocol
TLS 1.2 or 1.3. Below that, we say so.
HSTS
max-age, includeSubDomains, preload. Preload without a long max-age is wishful thinking.

Limits

We do not know if your ACME job runs. We see the cert now.

Port 80 has no certificate. Paste a host or an https URL. Private IPs are refused.

In practice

Why “37 days left” if I renew at 30?

We count to validTo, not to your cron. If Certbot runs at 30 days you stay green until the next cycle.

Self-signed?

TLS still opens (we do not abort) and the trust check fails. That is expected.

Should I set HSTS preload?

Only if you will never serve the domain on HTTP again, including subdomains. Otherwise a long max-age and includeSubDomains is enough.

Cross-check

A clean cert with empty headers is common. Run the header tool after this.

Free tools

WhatsApp Business