TLS

Your certificate is valid and still wrong

Expiry is the failure everyone monitors, because it is the only one with a date attached. The others do not announce themselves — they wait until a client that is stricter than your browser tries to connect.

Written by a network security engineer · last reviewed 20 August 2026

The failures that have no date

Hostname mismatch

The certificate is valid, in date, correctly signed — and does not cover the name being requested. Common after a service moves behind a new hostname, or when a SAN list was updated for the apex but not the www variant.

A chain missing its intermediate

This is the one that produces the most confusing tickets, because it often works in your browser and fails everywhere else. Browsers can fetch a missing intermediate over AIA or fall back to a cached copy. Command-line clients, mobile SDKs, Java stacks and IoT devices frequently cannot. So the site looks fine to the person testing it and breaks for an integration partner.

Test with openssl s_client -connect host:443 -showcerts against a machine that has never seen the chain, not with a browser you use daily.

Obsolete protocols behind a perfect certificate

A host can present a flawless certificate and still negotiate TLS 1.0. The certificate check passes; the connection is still weak. Certificate monitoring and protocol monitoring are different jobs, and most tools only do the first.

Weak keys and legacy signatures

These survive renewals. A renewal reuses the existing key and CSR unless someone deliberately rotates, so an undersized key from years ago quietly persists through every renewal that nobody actually reviewed.

Renewal automation that stopped

ACME automation fails silently more often than people expect — a changed DNS provider credential, a moved webroot, a firewall rule that broke the challenge. The renewal has not failed loudly; it has simply not run. You find out thirty days later, or you do not.

The check worth adding first, whatever tooling you use: alert on certificate age, not only on days-to-expiry. A certificate that should renew every 90 days and is now 75 days old tells you the automation is late — while there is still time to fix it calmly.

What to monitor, in priority order

Expiry — with enough lead time to act, not a 24-hour warning.
Renewal freshness — as above; catches broken automation before it becomes an outage.
Hostname coverage — every name you actually serve, including the ones nobody remembers adding.
Full chain as served — validated from a machine with no cache.
Negotiated protocol and cipher — what the server actually agrees to, not what the config says.
Key size and signature algorithm — checked at every renewal, not once at issuance.

CertLight

Self-hosted TLS and certificate monitoring with configuration grading — it checks the list above rather than stopping at the expiry date. Single Go binary, SQLite, embedded UI. No telemetry, and it runs entirely on your infrastructure, which matters when the list of hostnames you monitor is itself sensitive.

Run it

Grab the tarball and SHA256SUMS from the releases page, then:

sha256sum -c SHA256SUMS
tar xzf certlight-free-0.1.1-linux-amd64.tar.gz
cd certlight-0.1.1
./certlight
# dashboard on http://127.0.0.1:8422 — add your first host

Source on GitHub Other Hexward tools

Honest limits

It observes from wherever you run it. A host reachable only from inside a segment needs a probe inside that segment.
It monitors; it does not renew. Your ACME client keeps that job.
Grading is opinionated. Disagree with a grade and the underlying facts are still shown — check those, not the letter.
It will not find hosts you did not tell it about. That is a different tool — see below.

The certificate you are least likely to be monitoring is the one on the host you forgot you had: attack surface discovery.