fix(san-cert): honor per-service --tls-staging in the SAN cert manager

[mhenrixon]

Summary

--tls-staging never reached the shared SAN cert manager: the flag set ServiceOptions.ACMEDirectory, but that field only fed the per-service autocert path. Whenever the proxy runs with --acme-email, every service's certs come from the SAN manager, which issued everything — deploy hosts and --tls-domains-source dynamic domains alike — against the run-level --acme-directory (production by default). That's how ~1,000 staging-intended test subdomains burned a zone's weekly production rate limit.

This PR makes the manager keep one ACME identity per directory and honors the per-service directory end-to-end:

• internal/server/san_cert_directories.go (new): per-service directory overrides (SetServiceDirectory), domain→owner→directory resolution (registered, dynamic, pending, wildcard-via-covered-name), per-directory client bundles with lazily registered accounts, and the obtainersFor resolver.
• internal/server/san_cert_issuance.go: obtainCertificate — the one choke point every issuance path funnels through — picks the owning service's identity; strategy (DNS-01 zone routing, HTTP-01 fallback, wildcard refusal) is unchanged per identity.
• internal/server/san_cert_manager.go: registeredDomains now tracks owners (rebuilt on boot, no state impact); ManagedCert records its issuing Directory (omitempty, old state files read as run-level); the handshake batch path partitions pending domains by directory so one order never mixes identities. The dynamic issuer needed no change — its batches are already single-service.
• internal/server/domain_renewal.go: a directory mismatch (staging↔production flip) re-issues on the next reconcile instead of at the renewal window; a cert with no resolvable owner keeps its recorded directory (no churn while services re-attach after a restart). ARI queries route to the cert's recorded directory; an unbuilt bundle falls back to the window heuristic rather than registering an account for a read-only query.
• internal/server/service.go + service_options_validation.go: the deploy wires SetServiceDirectory before registering hosts, and ACMEDirectory must parse as an http(s) URL (it arrives over RPC; the CLI only ever sends the staging constant).
• internal/server/cert_store_{export,archive,restore}.go: per-directory account files (acme_user_staging.json, acme_user_<hash>.json) are part of the exported estate — previously the exporter warned on them and the strict archive reader rejected them.

Account file naming: the run-level directory keeps acme_user.json (existing accounts keep working on upgrade); the well-known LE staging URL gets acme_user_staging.json; anything else acme_user_<sha256[:8]>.json.

Closes #99

Test plan

• make test — full suite green
• go test -race ./internal/server/ — 1801 tests, no data races
• gofmt -l internal/ cmd/ — empty; make lint — 0 issues; go vet ./... clean
• make build — clean
• make docker smoke test — skipped locally (Docker daemon not running); CI builds the image
• New coverage: directory/owner resolution, account-file naming, cert provenance stamping + legacy-state load, per-directory obtainer selection, handshake batch partition, deploy wiring, renewer switch behavior, ACMEDirectory validation, export/restore round-trip of the extra account keys and the Directory field

Deviations & judgment calls

• Export/import got full per-directory account-file support, beyond the plan's round-trip assertion. The exporter warned "unexpected file" on acme_user_staging.json and the strict archive reader rejected archives containing it — without explicit support, a staging identity would be silently dropped from backups. Extra keys get the same parse/ECDSA validation as the primary.
• ARI needed routing too (discovered, not planned): managerObtainer.GetRenewalInfo was hardwired to the primary client, but a staging cert's ARI record lives at the staging CA. Routed by the certificate's recorded directory; reconcile checks directoryChanged before shouldRenew so ARI is never consulted at a directory that a pending switch has already invalidated.
• One shared issuance token bucket across directories — staging orders ride the same ceiling as production. Conservative: the bucket guards the per-account ACME limit, and splitting it would double allowed volume without evidence it's needed.
• Wildcard owner resolution is first-match over covered concrete domains. Real flows can't make it ambiguous (directory partitioning happens before wildcard collapse, within one batch); the race run caught exactly this ambiguity in a test fixture with two services under one root — fixed the fixture, not the code.
• Stale serviceDirectories entries linger after service removal, consistent with registeredDomains; both self-heal on redeploy/restart, and the renewer's unknown-owner rule keeps orphaned certs from churning.
• san_cert_manager.go is at 925 lines on dash — the coding-style rule's "688, near the ceiling" note is stale. This branch adds ~25 net lines there; all new logic lives in san_cert_directories.go. Splitting the manager file is real debt, but out of scope here.

---

Summary by cubic

Honors per‑service --tls-staging in the shared SAN cert manager by keeping one ACME identity per directory and routing issuance, renewal, batching, and ARI by the owning service. Prevents accidental production issuance and handles directory flips safely.

• Bug Fixes

  • Records per‑service directory via SetServiceDirectory and resolves by domain owner (registered/dynamic/pending/wildcard); batches never mix directories, including the handshake path.
  • Renewal re‑issues immediately on directory change, splits mixed‑directory certs into one order per desired directory, and pins each partition’s order to its computed directory via ObtainAt; adoption stamps Directory. ARI “replaces” is sent only when staying with the issuing CA and is spent only once the CA accepts an order (CA refusal keeps it for later; local adoption failure still consumes it). Unknown‑owner certs keep their recorded directory.
  • RegisterDomain’s “already covered” fast path requires a matching directory; mismatched covers are treated as due for replacement by GetCertificate and HasValidCertificate.
  • Wildcards: ownership checks only consider domains the cert still serves; concrete domains outrank wildcard scans deterministically.
  • ARI queries route to the cert’s recorded directory without creating accounts.
  • DNS‑01 clients are built per directory; HTTP‑01 handler is shared. Certificates stamp their Directory.
  • Deploy wires the per‑service directory before host registration and clears it when a service stops using the shared manager.

• Migration

  • Backups include per‑directory account files: acme_user_staging.json and acme_user_<hash>.json; restore writes them back and validates keys. Account‑only stores export cleanly.
  • ServiceOptions.ACMEDirectory must be an http(s) URL.

^{Written for commit e646d00. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 16 files

Confidence score: 4/5

• In internal/server/cert_store_archive.go, archive validation currently accepts unexpected certs/acme_user_*.json filenames, which could restore unintended ACME identities from crafted or malformed archives and lead to incorrect certificate account state—tighten matching to only acme_user_staging.json or an 8-character lowercase hex suffix to align with documented behavior.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="internal/server/cert_store_archive.go">

<violation number="1" location="internal/server/cert_store_archive.go:275">
P3: Unexpected `certs/acme_user_*.json` names pass archive validation and are restored as ACME identities; constrain matching to `acme_user_staging.json` or an 8-character lowercase hex hash so archives retain the documented closed entry set.</violation>
</file>

<sub>Tip: instead of fixing issues one by one fix them all with cubic

Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 9 files (changes from recent commits).

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

0 issues found across 7 files (changes from recent commits).

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}