Hub — the Manage page¶

Manage (/manage) is the Hub's operational home: every endpoint the Hub knows about, grouped per certificate so that one row is one renewal. It is deliberately one view — there is no managed/unmanaged page split and no alternate "by hostname" mode. Filtering is done from the summary strip, and everything the Hub knows about is on the page somewhere: no endpoint is ever hidden.

The page has four parts, top to bottom:

Estate summary — eleven counts that double as filters.
+ Add endpoint — the one way to create an endpoint by hand.
Certificates — the estate list, one group per certificate.
Not managed — certificates on which no endpoint is managed, under their own heading below the working set.

For the two facts behind every row — proof and management — see Endpoints, proof, and management. For why rows group the way they do, see Certificates: identity and observation.

The summary strip¶

Under the Estate summary heading, eleven cards each show a state and its count. Clicking a card filters the list to that state; clicking the active card again clears the filter. Every nonzero count has matching rows, because the counts are tallied from the same rows the table renders.

Card	Counts endpoints that are…
Healthy	managed, corroborated from both vantages, not near expiry
Partial	fine as far as the Hub can see, but from one vantage only
Attention	carrying a weakness or blocker that needs a human
Not serving	not serving the certificate that was installed on them
Renewing	in an in-flight renewal
Failed	in a failed state (unanimous renewal failure, break-glass, or a certificate/name mismatch)
Action needed	in a renewal that is waiting on the operator
Untracked	serving a certificate but not under management
Covered	unmanaged, but on a certificate a managed sibling already renews
Unproven	known by name only — never observed serving
Stale	proven once, but with no recent Scout observation

The estate list¶

The Certificates section is one table: Endpoint, Scout, State, Score, Expires, Action. Two buttons order it — By expiry (the default; this screen exists to prevent outages) and By Scout. Ordering never filters: both arrangements show the same rows.

The list has three shapes, one per kind of certificate:

Single-name certificate — a plain row for the hostname. No dropdown.
Multi-SAN certificate — a group: the header is the primary hostname (the certificate's CN, a served endpoint in its own right), and the dropdown lists every hostname the certificate covers, the primary included, each with its own state.
Wildcard certificate — a group whose header is the certificate itself, *.example.com. The dropdown lists the hostnames actually served under it. The wildcard is never a hostname row — nothing serves the literal *. name — so its state is the certificate's: renewal progress, expiry, and whether anyone serves it ("No host serves this certificate" when nobody does yet). It stays a header even with an empty dropdown.

Groups with more than three rows start collapsed; the header's toggle expands them.

Beside a hostname, a SAN or Wildcard chip says the certificate is shared — the endpoint renews together with siblings you may not see without expanding the group. An endpoint with no Scout shows No Scout in the Scout column; a score built from Scout evidence alone carries an Internal only badge.

Which Scout serves a hostname is something you declare, not something the Hub can detect (SERVE-DECL-1): two boxes holding the identical multi-SAN certificate are indistinguishable from every network vantage — a default vhost answers any SNI with a covering certificate — so the Scout mirrors its targets.conf (the endpoints its box serves, one host[:port] per line) to the Hub on every report, and the Scout column anchors on those declarations:

Declared on one Scout — the row shows that Scout alone, even when another box holds a copy of the certificate.
Declared on several (a load balancer with identical backends: put the line in each box's file) — all of them show.
Declared nowhere — every active Scout holding the certificate is listed, with a tooltip saying the list is holders, not a serving claim, and where to declare. The SAN/Wildcard chip carries the same names when there is more than one (SAN · api-io, vault-io).

+ Add endpoint writes the declaration for you (you pick the Scout in the form; the Scout appends the line), and Delete removes it. Demote does not — it ends management, not serving. Hand edits to the file are always honored: it is read fresh each cycle and the Hub's copy follows the next report. A single-Scout row reads exactly as it always has, and the group header's Scout column shows the union across its endpoints, so a collapsed group still says where the certificate lives.

Below the certificates, the Not managed section holds certificates on which no endpoint is managed — Untracked, Unproven, and Stale rows. They are context, not the working set: the Hub observes them but renews nothing. A certificate with even one managed endpoint stays up in Certificates, each of its endpoints showing its own state.

Row states¶

Each endpoint row carries a state chip and a single state-appropriate action. Both come from the server; the table below lists every label the page can show, in the order the Hub decides them (an earlier state always wins — a Stale row is Stale even if it is also expiring).

State label	Meaning	Row action
Stale	Had served proof once, but no active Scout has observed it in 30 days	Detail
Unproven	Not managed and never observed serving	Detail
Untracked	Not managed, but served proof exists	Adopt on a standalone row; inside a group the certificate's header carries the one Adopt N endpoints instead — see below
Covered	Untracked, but a managed sibling's certificate already renews it	none of its own — the header's Adopt N endpoints includes it
Mismatch	Measured score of 0 — the certificate does not match the hostname	Review Mismatch
Failed	Every renewal in the latest cohort failed, or the endpoint is in break-glass	Review Failure
Partial failure	Some of the certificate's renewals failed, but not all	Review Failure
Action needed	A renewal is parked waiting on the operator	Review Action
Renewing	A renewal is in flight	View Progress
Declared, not serving	A `targets.conf` declaration says this box serves the endpoint, and its Scout shows no fresh serving evidence — the declared expectation is unmet (graced while a renewal is in flight)	Open Scout
Installed, not served	A certificate is installed on disk but nothing serves it	Open Scout
Not serving installed cert	The endpoint serves a different certificate than the one installed	Open Scout
Blocked	Delivery or issuance is unconfigured, the required Scout is offline, or the endpoint is degraded	Review Blocker / Open Scout
Edge stale	The Scout already sees a newer certificate than the outside world does — a delivery/reload lag	Review Deploy
Vantage mismatch	Internal and external views disagree, and not as a delivery lag (split-horizon DNS, wrong vhost, interception)	Review Mismatch
Needs Data	No certificate expiry is known	Review Blocker
Deploy Issue	Expiring, but a new certificate was recently installed — the endpoint just isn't serving it yet	Review Deploy
Needs Profile	Expiring with no renewal profile assigned, so no renewal can run	Assign Profile
Candidate	Expiring, but never observed serving — the Hub won't renew what it has never seen	Detail
Needs Renewal	Expiring, with a profile — ready to renew	Renew Now
Serving undeclared	Everything checks out on the wire, but no `targets.conf` declaration stands behind what this endpoint serves — on a box that does declare. A default vhost can make a dead name pass every probe; only your declaration knows better	Details
Partial	Healthy as far as one vantage can tell; the other has no current evidence	Review Coverage
Waiting on re-check	Nothing has looked since the newest certificate arrived, so no serving verdict is issued yet	Details
Healthy	Managed, corroborated, and not near expiry	Details

Notes on the adopt states:

One Adopt per certificate (operator ruling 2026-09-02: "you adopt a certificate, not an endpoint"): a group's header carries the single Adopt N endpoints offer and no member row carries its own. The form opens on the certificate's renewal profile when any member already has one (every endpoint on the certificate moves with the pick); only a certificate with no profile anywhere asks with an empty picker. A standalone endpoint IS its own certificate and keeps its own row Adopt. See Adopt an endpoint.
Covered rows additionally explain themselves on hover: the endpoint is renewed as part of the certificate but has no renewal policy, autopilot, or delivery target of its own.

Under the state chip, a managed standalone row also shows an Autopilot / Manual chip — whether the Hub renews it unasked or only when you ask. Rows inside a group carry none: automation is a certificate-level fact, stated once on the group header. The State column carries nothing else — where a certificate lives, including its replicas, is the Scout column's job, and per-replica detail lives in the endpoint drawer.

Group headers¶

A group header is the certificate's line — the primary hostname for a multi-SAN certificate, *.example.com for a wildcard — with a count of the rows under it (shop.example.com — 3 endpoints, *.example.com — 2 hostnames). It carries certificate-level facts only:

Worst-of state — the state chip of the group's weakest endpoint, so a problem is visible without expanding. A Covered sibling never drags a healthy certificate's summary down; real findings do.
Automation chip — Autopilot, Manual, or Mixed. One chip for the whole certificate: enabling autopilot on any member applies it to the certificate's managed members together. Mixed means the members have not yet converged (only possible for rows written before automation became certificate-level); the first toggle clears it.
Aggregate score — the minimum of the members' known scores.
Expiry — the certificate's, stated once (member rows leave it blank).
Serving Scouts — the union of the members' serving Scouts, in the header's Scout column. When this same certificate is also installed and served from another Scout, that Scout appears here (and on each row it serves) rather than as a chip in the State column: the state is the state, and where the certificate lives is the Scout column's job. A replica Behind or Key differs still overrides the group's own worst-of state to Action needed, naming the Scout and the fix in one sentence, until it's resolved; each replica's state, path and Deliver again control live in the endpoint drawer. See Replicated certificates.
Group actions — Renew Now, when any member is due (the renewal is hoisted off the member rows: one certificate is one renewal, so one button, however many names it covers), and one Details opening the certificate's drawer.

The one Adopt N endpoints is also a group action (operator ruling 2026-09-02). The count in the label is load-bearing: a bare verb on a header labelled with the primary's hostname would read as an offer about that one endpoint, which is usually already managed. The POST goes to an adoptable member, and the profile picked in the form becomes the whole certificate's.

+ Add endpoint¶

+ Add endpoint (between the summary strip and the list) is the only way to create an endpoint by hand. Everything else on the page acts on an endpoint something already observed. The form asks for:

Field	Notes
Hostname	e.g. `shop.example.com` — or `*.example.com` for a wildcard, which needs a DNS-01 profile
Additional names	optional, one per line — extra Subject Alternative Names for a multi-SAN certificate (`example.com`, `api.example.com`). Plain hostnames only, no wildcards; the first issuance orders the hostname plus every name listed. Leave empty for a single-name certificate
Port	defaults to 443
Scout	required, and load-bearing: the chosen Scout (e.g. `web-01`) is where the certificate is deployed and from where the endpoint is tracked. The Scout must be active.
Renewal profile	required — see Renewal profiles

Submitting creates the endpoint, binds it to the Scout, and starts a first issuance. Every additional name gets its own row at the same moment — unmanaged and Unproven until something serves it — and the rows group under the certificate as soon as the Scout reports the installed file. You adopt the certificate once, from the group header, and its profile fans out to every name. The form tells you up front if a precondition is missing ("No active Scout…", "No renewal profile configured…") rather than letting you submit into a refusal. A refusal it does surface — "already in the fleet", "a renewal is already in progress", "agent is not active", or an internal-CA profile chosen for a name the Hub classifies as public ("not classified as an internal name") — is real and worth reading, not a stale-offer retry case. Those refusals happen before anything reaches the Scout: no key is generated, nothing is ordered, and nothing is left behind.

The step-by-step walkthrough is Track a new endpoint.

The endpoint drawer¶

Clicking any hostname opens that endpoint's drawer at /manage/<id>. Three sub-views hang off it as routes of their own: /manage/<id>/findings, /manage/<id>/renewals, and /manage/<id>/scout-ops — reached through the row actions and links described below, and directly linkable.

The detail view¶

The main drawer shows, top to bottom:

Current posture — the score ring and the same state label as the row.
Certificate covers N endpoints — for a shared certificate, every sibling with its own score and state, worst first. Probe and Scan run from this drawer refresh all of them.
Endpoint proof — the proof fact in plain words: "Serving observed", "Never seen serving", or "Proof out of date", each with a sentence explaining it.
Certificate expiry and Private key (freshly generated, or reused and how old — see Key reuse).
Next action — what the Hub thinks should happen next (see below).
Automation — the current mode (Autopilot / Manual) and, when the Hub offers the transition, a switch that flips it. Enabling autopilot requires a healthy Scout, an assigned profile, and served proof.
Renewal profile — the assigned profile's name, issuance, delivery, and key handling, with Edit this profile (opens the profile editor) and Change renewal policy (moves this endpoint to a different profile).
Known certificates — each certificate seen at this endpoint: subject, expiry, fingerprint, the on-disk path renewal delivery writes to on that host, and a Source line saying how Cyphers came to know about it, with a per-certificate revoke button ("Revoke the … certificate expiring …") for any not already revoked. Source is one of:
- Delivered by Cyphers — a certificate a renewal installed here.
- On this Scout's disk — a file the Scout reported from the host.
- Seen served on the wire only — the Scout saw it on a live connection and reported no file for it. On its own this is ordinary: every certificate a renewal replaced was seen this way before it was replaced.
Two further markers appear where they apply:
- This is what this row reads from — the endpoint's expiry and state on the Manage list come from this certificate. Useful when an endpoint lists several and you need to know which one the row is talking about.
- A warning that this name serves this certificate and this Scout holds no copy of it, so Cyphers cannot renew or replace it here. That happens when the name resolves to a machine no Scout runs on, and also when the host serves a certificate you manage outside Cyphers (a manually installed OV certificate, say). Either way the renewal lifecycle does not reach it — adopt it onto a Scout that holds the file, or keep renewing it the way you do now.
- Replicas — when the row's own certificate is also installed and served on another Scout, Known certificates gains a Replicas sub-list beside that certificate's entry: each other Scout, its state (Current / Delivering / Behind / Key differs), how long it's been that way, and the on-disk path there. A Behind or Key differs replica also names the fix in plain words. A Behind copy converges on its own: the Hub re-sends the current certificate automatically within minutes (replicated certificates) — no action to click. Key differs needs the key re-copied by hand first; the next sweep then catches the Scout up.
- View findings — opens the findings view.
- Blockers and Available actions — anything stopping automation, and the remaining offers (below).

When a row disagrees with itself¶

An endpoint Cyphers does not manage can still be seen to serve something other than the certificate its Scout holds on disk. The row keeps its Untracked label — Cyphers will not accuse an endpoint it does not manage of misserving a certificate it never installed. Open the drawer: the observation is stated at the top of Known certificates, beside the certificates it is about:

This Scout holds a different certificate than this name serves.
This Scout holds a certificate for this name that nothing is serving.

Both are observations, not faults. The usual causes are a leftover file from a previous tool, or a name that now resolves somewhere else entirely. Read the Source lines just below to see which certificate is which.

The Next action card¶

The card's content tracks the endpoint's renewal state. Two cases are worth knowing in advance:

Add DNS TXT record — a manual DNS-01 order is parked waiting on you. The card lists every TXT record to add (name and value). The Hub re-checks the records every 30 seconds and completes the renewal on its own once every authoritative nameserver serves them — the CA is only asked to validate (a one-shot act that kills the order on a wrong answer) after the whole fleet agrees. Verify & Complete runs that check immediately. If a check found a nameserver still serving an old value, the card names it — normal right after an edit, while your provider's servers converge.
Complete renewal — a CA that has prevalidated every domain on the order parks it with nothing to add. The card offers Verify & Complete, but you rarely get to click it: the Hub's DNS watchdog re-checks parked orders every 30 seconds and completes a zero-challenge park on its own — which on a per-certificate-billed CA means the earlier Renew Now was already the paid action.

Other states include Action needed (issued and installed, but not yet observed serving — the card names the specific hang-up, such as a failed deploy hook, and the renewal completes automatically once the new certificate is seen serving) and Monitor renewal progress (a renewal is already in flight; let it finish).

When a renewal fails the card says why in one sentence — the cause and what to do, not the CA's raw error (that stays on Activity and the renewal history). The two shapes:

Renewal failed — the endpoint already had a certificate. Fix the cause the card names (a missing DNS record, port 80 unreachable, a rate limit and when it resets, an internal-CA profile on a public name), then Renew Now from the actions below.
First certificate not issued — the endpoint was created with + Add endpoint and its first order failed. The card offers Retry first issuance: the same names, Scout and renewal profile are ordered again, and the history links the retry to the failed attempt. This is the one renewal a never-served endpoint can start, because nothing can have served before its first certificate.

Available actions¶

The drawer advertises only mutations the endpoint's current state permits. An absent action is not proof the Hub would refuse it — the list narrows, one way only. The list is grouped in three, in this order, so you look in one place instead of reading every button: Scan (look at the endpoint — Scan Now, Probe Now), Lifecycle (act on the certificate — renew, verify, cancel, revoke, profile, grace period, autopilot) and Management (change what the Hub manages — stop managing, promote, delete, wildcard membership). The offers and their conditions:

Action	Offered when
Renew Now	proof exists, no renewal in flight, Scout not suspended — or the newest renewal is a failed first issuance from + Add endpoint, which Renew retries as the same order (see First certificate not issued above)
Emergency Renew	the endpoint is in break-glass and configured enough to try; asks for a reason
Adopt key from `<path>`	the Scout reported an unmanaged private key that key-reuse needs — see Adopt a private key
Probe Now (external)	the Hub can probe — needs no Scout, which is exactly what you want when the Scout is dark
Scan Now	the endpoint's Scout is connected (labelled Check current cert on a never-proven endpoint)
Stop managing this endpoint	the endpoint is managed (this is Demote). Audited: who, from/to state, delivery mode reset, renewals cancelled — visible under Settings → Logging and on Activity
Promote	the endpoint is unmanaged — the Adopt form
Delete this endpoint	every endpoint; type the hostname back to confirm. A managed endpoint is demoted first (renewals cancelled); history is kept. A wildcard deletes only its own row. Withheld while a live Scout still holds a certificate Cyphers delivered for the name — the next sweep would only recreate the row; remove the file on the Scout first (see Recover from refusals → Delete)
Enable Autopilot / Disable Autopilot	the state permits the transition (see the Automation card)
Change renewal policy / Assign a renewal profile	the endpoint is managed
Revoke the … certificate expiring …	per known certificate, unless already revoked
Set verification grace period	exactly one Scout serving row exists to hold the value
Scan Now / Probe Now (external)	not offered on a wildcard — it is a certificate, not an endpoint; scan or probe one of the hosts under it
Attach a host to this wildcard / Remove `<hostname>` (on the coverage card, which lists the hosts served under the certificate and states their count)	on a wildcard endpoint: attach an already-serving host to the wildcard, or detach one you attached. The attach form takes one label under a fixed `.zone` affix (type `api`, not `api.example.com`), so a host outside the zone cannot be entered. This is not + Add endpoint — that creates a new endpoint with its own certificate. Remove is offered only for hosts added through this wildcard and undoes exactly that attachment — it never touches an endpoint the wildcard merely covers by name, nor any endpoint's scans, serving or record
Retry Verification	the renewal installed but its verification failed or mismatched
Cancel renewal	a renewal is in flight — placed beside that renewal's records on the Next action card. Marks it cancelled and releases the Scout's parked work; the row goes back to whatever the certificate says — a cancel is not a failure and nothing is left to review. A fresh Renew Now starts over (a manual DNS-01 record's value changes)
Verify & Complete / Mark Verified	the parked DNS-01 and verified-close renewal states. For a manual DNS-01 renewal the Next action card lists each TXT record to publish — name and value, each with a Copy button — shows what the last check found at that name, and carries Verify & Complete beside the records it verifies

Renewal timing lives on the profile

Deploy windows, retry counts, and renewal timing are fields of the renewal profile, and the profile editor is their only home. The drawer links there rather than offering a second editor.

Findings, Renewals, and Scout ops¶

Findings — two score rings (Current score and Projected score — what fixing the findings would earn), then each finding with its deduction and remediation text. See The Cyphers Score.
Renewals — the renewal history: each attempt's status, when it started, what timed it, the key used (fresh or reused), and any error.
Scout ops — the assigned Scout (linking to its page), health, serving status, last-seen, recent commands, and Scout actions the state permits: Deploy Scout, Re-enroll, Disable Scout / Enable Scout, and Rename Scout.

When an action answers 409¶

Some actions re-check live state at POST time: Renew Now runs a renewal pre-flight, Revoke and Scan Now look the agent up live, and Attach a host to this wildcard probes the host. A 409 from these normally means the offer went stale — the estate moved between the page render and your click. The page re-reads and shows the fresh state; nothing is broken and there is nothing to fix.

The exception is a refusal: a decision that would repeat on every retry — the renewal pre-flight finding a real blocker, or the wildcard attach probe finding the host does not resolve or does not serve the wildcard's certificate. The Hub marks these (refused) and sends the reason, and the page shows it in a red alert next to the button, so the click never becomes a silent no-op.