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.
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.