Caddy's on-demand TLS ask calls http://tidepool:80/.well-known/tidepool-tls-ask, addressing this process by its container DNS name — so the request carries Host "tidepool", which the v2 host router recognizes as neither the bridge surface nor the user origin and refuses with 421. Every new bridged-handle certificate issuance and every renewal has been denied since the v2 deploy (observed in production 2026-08-22: 6 sampled refusals in 47h; cached certs masked the breakage). DEPLOY.md §4 claimed the gate was unaffected; it wasn't. The fix: HostRouterOptions.HostAgnosticPaths — paths served by the service handler BEFORE any Host judgment. main.go lists exactly one, the ask gate, via the new identity.TLSAskPath constant shared with the route registration so the two can't drift. The exemption is per-path, not per-host: an unrecognized Host asking for anything else keeps the 421 posture, and the ask endpoint itself is a read-only "is this domain a handle I'd serve" answer that was globally reachable pre-v2. Repro test first: TestHostRouter_HostAgnosticPaths exercises Caddy's exact request shape (docker-DNS Host + ask path -> 200 from the service surface), plus the negatives (other paths on that Host still 421, recognized hosts unchanged). Red before the fix, green after; mutation bite-check (exemption disabled) reddens it; personas/identity/cmd/tidepool suites pass DB-backed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>