Endpoints, proof, and management¶
Every row on the Manage page is an endpoint — a hostname (and port) the Hub knows about. Two independent facts describe each one, and keeping them separate is what makes the page honest:
| Fact | Question it answers |
|---|---|
| Proof | Has the Hub observed this endpoint serving a certificate? |
| Management | Has an operator put this endpoint under management? |
They are orthogonal, and every combination is meaningful:
- Proof without management is the normal starting state: a Scout saw the endpoint serving, nobody has adopted it yet.
- Management without current proof is a coverage gap: the endpoint is yours to renew, but nothing has confirmed lately what it serves.
The states you see¶
Untracked — the endpoint serves a certificate (proof exists) but is not under management. Its offer is Adopt. When the certificate that covers it belongs to a managed sibling — one certificate covering several names, some already adopted — the row is labelled covered instead: that certificate already renews on the sibling's behalf, which is why the row is quiet. A covered row still offers its own Promote, and eligible covered siblings are in any case adopted automatically once a renewal of the covering certificate verifies.
A host under a managed wildcard is the one covered row where Promote
means something different, and its form says so before you apply it. The
wildcard names *.example.com, not the host, so there is nothing of the
host's to add to the wildcard's renewal: adopting api.example.com makes it
an endpoint of its own. Its next renewal orders a certificate for
api.example.com alone, under the profile you pick for it; the wildcard
keeps its own profile, and the other hosts under it are not adopted along.
Leave the host as it is and it goes on renewing with the wildcard. Stop
managing the host later and it returns to the wildcard.
On disk, not declared as served here — a Scout that declares what its
box serves has found this name in a certificate file, and nothing declares
it as served. The Hub lists it with the Scout that holds the file and claims
nothing about serving: a box that declares its endpoints does not probe
names outside its declarations, so there is no outage to report, only a
file. Two ways out, both in the drawer: Declare and adopt (pick the
Scout and port that serve it; the Hub writes the targets.conf line and
manages the name) or remove the file on the Scout — Delete is withheld
while the file is there, because the next sweep would only recreate the
row. Expired leftovers surface the same way, showing their expiry.
Unproven — the Hub knows the name but has never seen it serve. All it offers is a probe. No renewal automation, no autopilot, no scoring-driven remediation: the Hub will not manage what it has never observed.
Stale — the endpoint had served proof once, but no active Scout has scanned it within the last 30 days (or the Scout that used to is gone). Staleness is a statement about freshness, not a revocation of proof: the endpoint is still known to have served, but nothing current confirms what it serves now. Hub-side probes do not reset this clock — only a Scout observation does, because staleness is specifically "no agent is watching this."
Managed — adopted, actively lifecycle-managed. This is where Renew Now, renewal profiles, and autopilot live. Live served proof is what authorizes the page's posture claims: the score, the findings, and any remediation offers all rest on a current observation.
There is no 'monitor but don't manage' state
Either an endpoint is managed or it isn't. A watch-only stratum was deliberately removed from the product: it reported nothing actionable and blurred the one question that matters. If you want the Hub renewing an endpoint, adopt it; if not, it stays Untracked and still gets observed.
Adoption and its inverse¶
Adopt is offered on the untracked endpoint's row — as a one-click Promote when its certificate group already has a renewal profile (the profile is inherited, not asked for twice), or with a profile picker when nothing in the group has one yet. Its effect is certificate-shaped: the profile you assign is written across the whole group, and once a renewal of that certificate verifies, eligible untracked siblings are adopted automatically (see Certificates: identity and observation for how groups work). That automatic sweep is deliberately conservative: it skips endpoints without served proof (an unproven name is never swept into management by a sibling), endpoints on a different Scout, and endpoints in protected postures — a group converges on managed without quietly erasing a state someone set on purpose.
Delete is the way back out, and it is available on every endpoint. It lives in the endpoint drawer and requires the hostname typed back — that is the safeguard. A managed endpoint is demoted as part of the delete: any in-flight renewal is cancelled and the Scout releases its parked work before the row goes. It removes the endpoint's row and its delivery wiring, but keeps history — scans, renewals, deployments, the audit trail — because those record what was true. Deleting a wildcard removes the wildcard's own row; the hosts served under it are their own endpoints and stay.
Coverage gaps are named, not dramatized¶
The Hub sees an endpoint from up to two vantages: internal (the Scout on the box, probing what it actually serves) and external (a probe from the Hub's network position). When one vantage is missing or not current, that is reported as a coverage gap — "waiting on re-check", "no external observation" — never as a disagreement. A mismatch verdict is reserved for two current observations that genuinely differ, because an alarm that fires on missing data teaches you to ignore alarms.