@@ -15,6 +15,21 @@ All notable changes to **Heliograph** are recorded here. The format follows
   versions: the CVE fixes still can't regress, and newer revisions install without breaking the build.
 
 ### Security
+- **Revoking and re-adding a vantage now retires its earlier certificates.** Agent authorization
+  checked only the client certificate's CommonName against the registry, so after
+  `smoked vantage revoke <name>` followed by `vantage add <name>` — the documented way to retire a
+  credential — every certificate ever issued for that name (CA-signed, valid for ten years)
+  authenticated again. The hub now records the serial of every certificate it issues and accepts a
+  certificate only if its serial was issued for the vantage's current registration; revoking drops
+  the recorded serials, so a re-added name accepts only certificates issued after the re-add.
+  Regenerate (the dashboard's **Regenerate**, or `vantage add` for a registered name) is unchanged:
+  earlier certificates keep working alongside the new one. **Upgrade:** vantages registered before
+  this release have no recorded serials, so on the first start they become *legacy* registrations
+  that keep accepting any hub-CA certificate bearing their name — deployed agents keep reporting
+  with no action — until they are revoked. Revoke and re-add such a vantage once (and redeploy its
+  new bundle) to bring it under serial checking. Certificates minted by an older `smoked` binary
+  against an upgraded database are not recorded and are refused for vantages registered after the
+  upgrade. See *Certificate serial tracking* in `docs/federation.md`.
 - **`golang.org/x/text` bumped from v0.39.0 to v0.42.0** for [GO-2026-6629](https://pkg.go.dev/vuln/GO-2026-6629)
   (a panic in `x/text/secure/precis`, fixed in v0.41.0). `govulncheck` flagged it through `pgx`'s
   SCRAM password handling. That path runs the operator-supplied database password through a
 
@@ -271,10 +271,12 @@ vantage**: type a name and it downloads a ready-to-run `<name>-vantage.tar.gz`
 to print the rendered `agent.yaml` to stdout, or pass `-json` for the raw PEMs). The panel also
 **list**s vantages and lets you **regenerate** one — issuing and downloading a fresh certificate
 bundle for an existing name, which does *not* invalidate the certificate already deployed there
-(there's no revocation list; both stay valid until the vantage is revoked). Revocation is by
-removal: `smoked vantage revoke <name>` deletes it from the registry, and any certificate bearing
-that name is rejected on its very next request even though the certificate itself remains
-cryptographically valid. To fully retire a credential, revoke the vantage and re-add it.
+(both stay valid until the vantage is revoked). Revocation is by removal: `smoked vantage revoke
+<name>` deletes it from the registry, and every certificate issued for that name is rejected on
+its very next request even though the certificate itself remains cryptographically valid. The hub
+records the serial of each certificate it issues and accepts only those issued for a vantage's
+current registration, so to fully retire a credential, revoke the vantage and re-add it: the
+re-add's fresh bundle works, and no certificate issued before the revoke is accepted again.
 
 **Bundled Caddy** (automatic Let's Encrypt, dashboard only) — opt-in via the `federation` compose
 profile:
@@ -529,8 +531,8 @@ internal/
   mcp/           MCP server (stdio) — diagnosis tools + a stage/review/apply config-write flow
                  over the same HTTP API, for AI-assisted operation (+ tests)
   federation/    per-vantage assignment builder + measurement fingerprint
-  vantage/        per-vantage registry + self-bootstrapped CA (mTLS client-cert auth; revoke by
-                  removing the name)
+  vantage/        per-vantage registry + self-bootstrapped CA (mTLS client-cert auth by name +
+                  issued serial; revoke by removing the name)
   agentwire/     shared hub<->agent wire types
   agent/         smoke-agent buffer + on-disk spool + hub client
   importer/
 
@@ -52,9 +52,10 @@ password-gated admin API, both of which mint the client certificate. Federation
 - ✅ Per-round vantage dimension in the store (the hub probes as `local`)
 - ✅ `vantages:` config (inherited down the tree) + a pure per-vantage assignment builder + a
   content-version hash for the `304` check
-- ✅ Vantage registry + a self-bootstrapped CA (mTLS client-cert auth by CommonName;
-  revoke-by-removal — deleting a vantage rejects its certificate on the next request even though
-  the certificate itself remains valid) + `smoked vantage add/ls/revoke` CLI + a password-gated
+- ✅ Vantage registry + a self-bootstrapped CA (mTLS client-cert auth by CommonName + issued
+  serial; revoke-by-removal — deleting a vantage rejects its certificates on the next request even
+  though they remain valid, and re-adding the name accepts only newly issued ones) + `smoked vantage
+  add/ls/revoke` CLI + a password-gated
   `/api/admin/vantages` API with a session login
 - ✅ Agent-facing endpoints: `GET /agent/v1/assignment` (304-aware, carries effective probe-level
   config) + `POST /agent/v1/results` (mutual-TLS client-certificate auth, validated + idempotent
 
@@ -109,9 +109,9 @@ name and it downloads a ready-to-run `<name>-vantage.tar.gz` — `agent.yaml`
 unpack it, and `docker compose up -d` — no key, ever. The panel also **list**s
 vantages (name, created, last-seen, target count), **regenerate**s one (issues
 and downloads a *fresh* certificate bundle for an existing name — the
-previously issued certificate keeps working, since there's no revocation list;
-to actually retire a credential, **revoke** the vantage and re-**add** it), and
-**revoke**s one (removes it from the registry — see Security model below).
+previously issued certificate keeps working too; to retire every earlier
+certificate, **revoke** the vantage and re-**add** it), and **revoke**s one
+(removes it from the registry — see Security model below).
 It's reached through the proxy (behind the dashboard's Basic Auth, then its
 own admin password) or on `http://localhost:8087/` on the hub.
 
@@ -149,11 +149,19 @@ revoked vantage "nyc"           # this CN is rejected on its very next request
 ```
 
 Revocation is by **removal from the registry**, not certificate expiry or a
-CRL: `requireAgent` looks up the presented certificate's CommonName against the
-active vantage list on every request, so a revoked vantage is locked out
-immediately even though its certificate itself remains cryptographically
-valid until it expires. Re-running `vantage add <name>` for a revoked name
-re-registers it and issues it a fresh certificate.
+CRL. The hub records the serial number of every certificate it issues, and on
+every request `requireAgent` checks that the presented certificate's CommonName
+is a registered vantage *and* that its serial was issued for that registration.
+Revoking deletes the vantage together with its recorded serials, so it is
+locked out immediately even though its certificates remain cryptographically
+valid until they expire. Re-running `vantage add <name>` for a revoked name
+re-registers it and issues a fresh certificate — and only that certificate is
+accepted; every certificate issued before the revoke stays rejected. In short:
+
+- **Regenerate** (dashboard, or `vantage add` for a registered name) adds a
+  certificate; the ones issued earlier keep working.
+- **Revoke, then re-add** retires every earlier certificate for the name; only
+  the new bundle works. This is how to retire a leaked or replaced credential.
 
 ## Step 3 — Run the agent at the vantage
 
@@ -245,12 +253,15 @@ spool_dir: /var/lib/smoke-agent/spool
   (`RequireAndVerifyClientCert`) before any request reaches a handler; a
   request presenting no certificate, or one not signed by the hub's CA, never
   gets that far. There is no bearer token to leak, forward, or accidentally log.
-- **Authorization is the certificate's CommonName**, checked against the active
-  (registered, not revoked) vantage list on *every* request — so revoking a
-  vantage takes effect on its very next request even though the certificate
-  itself remains cryptographically valid. A CN that isn't a currently active
-  vantage → `403`; no client certificate at all → the TLS handshake itself
-  fails before an HTTP status is ever produced.
+- **Authorization is the certificate's CommonName and serial number**, checked
+  on *every* request: the CN must be an active (registered, not revoked)
+  vantage, and the serial must be one the hub issued for that registration. So
+  revoking a vantage takes effect on its very next request even though the
+  certificate itself remains cryptographically valid, and re-adding the name
+  later does not revive it. A CN that isn't a currently active vantage, or a
+  certificate not issued for its current registration → `403`; no client
+  certificate at all → the TLS handshake itself fails before an HTTP status is
+  ever produced.
 - **The hub is authoritative** for each target's probe/host; the agent only sends
   raw round-trip times for its assigned targets. Unassigned or malformed results
   are dropped and counted.
@@ -286,6 +297,19 @@ retention window** — the raw rows behind them are already gone, so the long-ra
 logs a warning when this runs. If that history matters, snapshot the database
 before upgrading. New deployments are unaffected.
 
+### Certificate serial tracking
+
+Hubs at v2.2.0 and earlier did not record the serials of the certificates they
+issued. On the first start after upgrading, every vantage already in the
+registry is marked as a **legacy** registration: it keeps accepting any
+certificate signed by the hub's CA that bears its name, so its deployed agent
+keeps reporting with no action needed. Vantages added after the upgrade accept
+only certificates the hub recorded. A legacy vantage stays that way until it is
+revoked; to bring one under serial checking, revoke and re-add it and redeploy
+the new bundle — which also retires every certificate issued for it before.
+Mint certificates with the upgraded `smoked`: one minted by an older binary is
+not recorded, so a vantage registered after the upgrade rejects it.
+
 ### Agent fingerprint migration
 
 Each agent round now carries a **measurement fingerprint** so the hub can reject a
@@ -345,8 +369,10 @@ a path reuse can pause data.
   vantage) to get a bundle matching the hub's current CA.
 - **Agent gets `403 unknown or revoked vantage`** — the certificate is valid
   and trusted, but its CommonName isn't a currently registered vantage (never
-  registered, or `vantage revoke`d). `vantage add <name>` (re-)registers it and
-  issues a fresh certificate; update the agent with the new bundle.
+  registered, or `vantage revoke`d), or the certificate was issued before the
+  vantage was last revoked (an old bundle still deployed after a revoke and
+  re-add). `vantage add <name>` (re-)registers it if needed and issues a fresh
+  certificate; update the agent with the new bundle.
 - **Vantage never appears / `LAST-SEEN never`** — the agent can't reach the hub
   on its mTLS port (DNS/firewall/`-agent-addr` not published), or no target lists
   that vantage. Check the agent log and that `vantages:` includes the name;
 
@@ -8,6 +8,7 @@ import (
 	"crypto/tls"
 	"encoding/json"
 	"io"
+	"math/big"
 	"net/http"
 	"net/http/httptest"
 	"strings"
@@ -37,7 +38,7 @@ func (f *fakeKeys) Revoke(_ context.Context, name string) (bool, error) {
 	f.revoked = append(f.revoked, name)
 	return name == "nyc", nil
 }
-func (f *fakeKeys) IsActive(_ context.Context, name string) (bool, error) {
+func (f *fakeKeys) IsActive(_ context.Context, name string, _ *big.Int) (bool, error) {
 	return name == "nyc", nil // mirrors List(), which only knows about "nyc"
 }
 
 
@@ -18,13 +18,15 @@ func vantageFrom(r *http.Request) string {
 	return v
 }
 
-// requireAgent authorizes a federation agent by the CommonName of its mTLS client certificate.
-// It does not perform the TLS handshake itself: the mTLS listener (wired separately, a later
-// task) already requires a CA-signed client cert before a request ever reaches a handler here —
-// this layer only authorizes the identity that cert presented, the same shape as requireAdmin
-// authorizing an admin session. A CN must belong to a currently active (registered, not
-// revoked) vantage; on success it is stamped onto the request context via vantageCtxKey exactly
-// as the old Bearer-key auth did, so vantageFrom/agentAssignment/agentResults need no changes.
+// requireAgent authorizes a federation agent by its mTLS client certificate. It does not perform
+// the TLS handshake itself: the mTLS listener (AgentTLSConfig) already requires a CA-signed
+// client cert before a request ever reaches a handler here — this layer only authorizes the
+// identity that cert presented, the same shape as requireAdmin authorizing an admin session. The
+// CN must belong to a currently active (registered, not revoked) vantage AND the certificate's
+// serial must be one issued for that registration (Vantages.IsActive), so a certificate minted
+// before a revoke stays rejected after the same name is re-added. On success the CN is stamped
+// onto the request context via vantageCtxKey, so vantageFrom/agentAssignment/agentResults need
+// no changes.
 //
 // SAFE ONLY behind a listener whose tls.Config sets ClientAuth: tls.RequireAndVerifyClientCert
 // (the config AgentTLSConfig, in agentmtls.go, produces). A weaker ClientAuthType such as
@@ -43,8 +45,9 @@ func (srv *Server) requireAgent(next http.HandlerFunc) http.HandlerFunc {
 			http.Error(w, `{"error":"vantage store unavailable"}`, http.StatusInternalServerError)
 			return
 		}
-		cn := r.TLS.PeerCertificates[0].Subject.CommonName
-		active, err := srv.Vantages.IsActive(r.Context(), cn)
+		leaf := r.TLS.PeerCertificates[0]
+		cn := leaf.Subject.CommonName
+		active, err := srv.Vantages.IsActive(r.Context(), cn, leaf.SerialNumber)
 		if err != nil {
 			http.Error(w, `{"error":"store unavailable"}`, http.StatusServiceUnavailable)
 			return