Terminology
Certificate work is full of words that are used loosely and then relied on precisely. This page maps the vocabulary onto the fields an actual check returns, so a monitor and a runbook can mean the same thing.
| Term | What it means, and where it appears |
|---|---|
| SSL vs TLS | SSL is the retired protocol; TLS replaced it. The word SSL survives in product names and certificate wording. Every connection ExpiryBeacon makes is TLS, and the negotiated version is reported with each check. |
| notBefore / notAfter | The two timestamps that define the validity window, in UTC. “Expiry” always means notAfter. Both are shown as valid from and valid until. |
| Leaf certificate | The end-entity certificate for your hostname. This is the one that expires on the date you care about, and the one the days-remaining figure describes. |
| Intermediate | A certificate that links your leaf to a trusted root. It has its own expiry, and a server that fails to send it produces trust failures that look intermittent. Chain depth reveals whether it was sent. |
| Root | The self-signed anchor in the client's trust store. Roots expire too, but on a decade-long scale and outside your control. |
| Subject alternative name (SAN) | The list of hostnames a certificate is valid for. Modern clients read this list, not the common name. Every SAN entry is listed in a check result. |
| Wildcard | A SAN entry such as *.example.com, matching one label only. It covers app.example.com but not a.b.example.com, and the apex needs its own entry. |
| Fingerprint | A SHA-256 hash of the certificate. Two endpoints serving the same fingerprint are serving the same certificate — the quickest way to confirm a renewal reached every node. |
Monitoring the leaf is necessary and not always sufficient. An intermediate certificate has its own validity window, and when one is retired the practical symptom is a trust failure rather than an expiry notice — clients that cannot build a path to a root simply refuse the connection.
That is why a check here reports trust and expiry as separate results. A certificate can be well inside its window and still fail validation, and a monitor that reduces both to one green tick will tell you everything is fine right up until it is not.
Chain depth is the cheap diagnostic. A publicly issued certificate served alone, with a depth of one, means the intermediate is missing from the server configuration even though desktop browsers may hide the problem with a cached copy.
There is no discovery in ExpiryBeacon — you add each endpoint yourself — so it is worth being systematic about the list.
One certificate can cover dozens of names, and one name can be served by several origins. Monitor each endpoint that actually completes a handshake.
A wildcard does not cover the bare domain. If both are served, both deserve a monitor, because they can drift onto different certificates.
Admin interfaces and APIs on 8443 or 9443 are the ones people forget, and they are usually renewed by a different process from the main site.
A monitor nobody can explain is a monitor nobody will act on. Accounts hold up to 50, which is a useful upper bound on a list you can actually maintain.
They describe the same job. “Certificate” is the more accurate word because the protocol is TLS, but the terms are interchangeable in practice and ExpiryBeacon treats them as one product.
You cannot add an intermediate as its own monitor, but you do not need to. Each check validates the whole chain the server presented, so an intermediate problem shows up as a trust failure on the endpoint that has it.
One monitor per endpoint that terminates TLS. A single wildcard certificate can be served by several origins with different renewal processes, and only a per-endpoint check will notice when one of them falls behind.
No. ExpiryBeacon connects with direct TLS on 443, 8443, and 9443. Mail protocols using STARTTLS, client certificates, and code-signing certificates are out of scope.