Certificates
Inventory, expiry and chain trust
Edit this pageOn this page
Every TLS handshake a daemon performs records the certificate it was presented. That turns two questions that are normally a spreadsheet — what expires next month, and what is still using a self-signed certificate we forgot about — into filters.
How certificates are collected
Passively, as a side effect of discovery. When the daemon finds a service speaking TLS it completes the handshake, records the chain, and moves on. It does not connect to anything it did not already discover.
Set LOOMSCOPE_TLS_DISABLED=true on a daemon to skip the handshake probe
entirely — worth doing only where a handshake against a fragile device is a
real risk.
The list
| Filter | Options |
|---|---|
| Expiry window | 30, 60 or 90 days |
| Self-signed | Only certificates that sign themselves |
| Trust status | Trusted, untrusted, self-signed, expired |
| Site | Scoped by the header picker like everything else |
The expiry column colours by urgency, and expired certificates are shown as overdue rather than hidden. A certificate that expired last week is more interesting than one expiring next month, and dropping it out of the default view is how it gets missed.
Trust status
The chain is verified against the system trust store at collection time, and the result recorded:
| Status | Meaning |
|---|---|
trusted | Chains to a root in the trust store, and is currently valid |
self_signed | The leaf signs itself |
untrusted | Does not chain to a known root — a private CA, or an incomplete chain sent |
expired | Chains correctly but is outside its validity window |
untrusted is not the same as wrong. An internal CA that is not in the
daemon's trust store produces it, and the fix is to add the CA rather than to
replace the certificate. Mount your root into the daemon container and the
status resolves to trusted.
Self-signed detection checks the leaf's signature against its own key
directly, rather than asking whether it is a valid CA — a self-signed leaf
with CA:false is extremely common and would otherwise be reported as not
self-signed.
A certificate page
Subject, issuer, validity window, key algorithm and size, SANs, fingerprint, and every host and service it was seen on. That last part is the useful one: a wildcard certificate deployed on eleven machines is one certificate with eleven places to replace it, not eleven separate problems.
Expiry alerting
The notify.certificates job runs hourly and emits tls.expiring events as
each threshold is crossed.
Deduplication is by certificate and threshold, so a certificate found every hour announces once at 30 days, once at 14, once at 7 — rather than once an hour for a month. The cost of asking often is a query, not an alert.
Route it to Slack, Teams, PagerDuty, Jira or a signed webhook under Settings → Integrations. See Notifications.
What this does not do
- It does not renew anything. Loomscope is an inventory, not an ACME client.
- It does not see certificates on services it did not discover. A TLS endpoint behind a firewall that drops the probes is invisible here, like everywhere else.
- It does not evaluate cipher suites or protocol versions beyond recording what the handshake negotiated. A dedicated TLS scanner does that better.