Repository navigation
fix(web): first-run bootstrap — do not gate on an operator cert before a signed Root CA exists #70
Description
Finding (surfaced during ESXi E2E, 2026-07-21)
auth-gate.tsx denies with "No valid operator certificate" whenever WhoAmI does not resolve to an operator. But at true first setup a fresh fleet has no signed Root CA and therefore no operator CA to issue operator certs — a chicken-and-egg: you cannot get in to create the Root CA, and you cannot issue an operator cert until the Root CA (operator CA) exists.
Shane: "not until you have at least one signed Root CA" — the operator-cert gate must be conditional on the fleet being bootstrapped.
Proposed
- Manager reports fleet bootstrap state (is there >= 1 established Root CA / is an operator CA configured?).
- Web
auth-gate: when NOT bootstrapped, enter a first-run setup mode that does not require an operator cert — enough to adopt/create the first Root CA and designate the operator CA, then issue the first operator credential (S9). - Once bootstrapped, enforce operator-cert auth as today.
Orthogonal to the dev authBypass path (which already skips the gate for local dev); real production first-run needs it. Part of the Full Web Parity program (manager#24).
Activity
Bugs5382 commentedon Sep 17, 2026
Status update after #79 / #80 and manager#68, which move the ground this was written on.
What is now solved: the page is reachable at all. Previously the manager required a client certificate during the TLS handshake, so a first-run operator with no certificate got
ERR_BAD_SSL_CLIENT_AUTH_CERTand no response — a first-run setup mode could not have been delivered to them even if it existed. The manager now serves the web surface anonymously (VerifyClientCertIfGiven, with the auth middleware gating the API only), and the landing page renders for someone holding no certificate.What is still open — this issue's actual substance: the gate still denies without an operator identity, so a first-run operator reaches the landing page, presses Log in, and is told "No operator certificate presented". On an unbootstrapped fleet that is a dead end for exactly the reason recorded here. The two proposed pieces both remain:
One thing worth deciding explicitly before implementing, which is why this was not folded into #79: an unauthenticated first-run path is an unauthenticated write path on a PKI. What it may do, and how it refuses once the fleet is bootstrapped, is a security decision rather than a UI one. The denial reasons added in #79 (
no-certificate,not-authorized,unavailable) give the gate somewhere to branch from, so the web side is a small change once the manager can answer "is this fleet bootstrapped?".fix(auth): tell a first-run operator where the first certificate come…
Bugs5382 commentedon Sep 25, 2026
Reopening: auto-closed by #106, whose body said "does not close" followed by this issue number, which GitHub read as a closing keyword. #106 only ships the stand-alone help text. The conditional first-run gate still depends on manager#78 (GetBootstrapState / BootstrapOperator).
fix(auth): tell a first-run operator where the first certificate come…
Bugs5382 commentedon Oct 6, 2026
Resolved by #151: BootstrapGate calls GetBootstrapState before the operator-cert gate. While first run is open, it opens the first-run wizard instead of refusing, and once the fleet is bootstrapped it falls back to the normal operator-cert sign-in.