nebula-mesh: Host revocation is not durable - blocked/offboarded hosts can regain a valid certificate

Summary

Two related authorization gaps let a host that should no longer be trusted obtain a fresh, valid Nebula certificate, because nebula-mgmt does not re-evaluate revocation/authorization state at certificate issuance time — only at poll time.

1. Blocklist not enforced at sign / re-enroll time

internal/api/enroll.go:128 calls caMgr.Sign(...) without consulting the blocklist. The blocklist is only checked in the poll path (internal/api/updates.go:57, fingerprintInBlocklist). The blocklist is keyed by certificate fingerprint (internal/store/sqlite.go), so a re-enrollment produces a new fingerprint that is not in the blocklist.

mintEnrollmentTokenForHost (internal/api/hosts.go:491) authorizes the caller via canAccessHost but does not check the host status. There is no guard preventing a blocked host from transitioning back to enrolled (internal/store/sqlite.go, enrollHostInTx updates status unconditionally).

Impact: A host that an operator has blocked can be silently un-blocked by issuing a new enrollment token and re-enrolling — it receives a fresh certificate (new fingerprint) that passes all subsequent poll-time blocklist checks. Revocation is therefore not durable. Requires an operator action (minting a re-enroll token), so this is an integrity/operational-revocation failure rather than an unauthenticated bypass.

2. Renewal does not re-validate operator / CA status

Auto-renewal at poll time (internal/api/updates.go:285-319, ) reads , , from the DB and re-signs without checking whether the owning operator is still active or the CA still valid. () revokes sessions and API keys but does not retire the operator's CAs, and checks only CA cert time-expiry, not operator/CA status.