Delegate VPN Certificate Issuance Without the Root Key

Handing somebody the ability to enroll VPN clients and handing them a portable copy of the root key are different acts, and the difference only becomes visible when that person leaves or that key leaks. The first grants an operation inside a workflow you control; the second grants the ability to mint trust anywhere, offline, indefinitely. Decide which one the job needs before touching any key material. A hierarchy diagram will not answer that question for you.

Write the enrollment job down as three questions: who may request, who approves, and what the issuing component is allowed to sign.

Decide Which Capability You Are Granting

An issuing service can expose an approval workflow while keeping signing material under a separate owner. An operator approves a device request, the service applies policy and records the issuance, and nobody involved holds the CA key. Document the permitted identities, the approvers, and the range of what the service can sign; then protect its administration as carefully as the key. A certificate signing request is a request, not an authorization decision.

Hardware-backed storage changes the risk of key copying, not the need for authorization. Non-exportable means the key cannot be lifted out, and it does not mean anyone able to call the signing interface is entitled to a certificate. Assess those two properties separately.

An Intermediate Bounds the Authority

A root can certify an intermediate for day-to-day issuance, so routine work no longer touches the root key, as long as the root's own signing and recovery procedures remain protected. That is a real boundary and it is not free: another certificate, another key, another renewal and another revocation list to maintain. Use one when it represents a deliberate management or risk boundary. Creating an issuer per administrator produces more of everything and buys nothing the workflow did not already provide.

Check that the VPN verifiers build the chain the way you expect. Shipping an intermediate for chain construction and installing it as a directly trusted anchor are different arrangements.

pathLen Zero Does Not Mean What You Think

RFC 5280 section 4.2.1.9 defines basic constraints, and its path length field limits how many non-self-issued intermediate certificates may follow in a valid path. A value of zero restricts further intermediate depth; it does not limit the number of end-entity certificates. People read it as zero certificates allowed and then wonder why issuance still works. Read the field as a depth limit on CAs, and the behaviour becomes predictable.

The same section implies a trust anchor is an input to path validation rather than an ordinary certificate inside the path. That is why publishing a revocation entry for a self-signed root does not reliably remove it from every store.

Offboarding Is Not a Key Compromise

Where the leaver held nothing but a personal management account, revoke that access and its sessions through the supported identity process, then review the activity and approvals it produced. Previously issued client certificates do not become invalid because their approver left, and treating them as compromised creates a large, unnecessary re-enrollment. Disabling an account cannot invalidate a copied signing key either, so the response depends on which capability was held.

When an intermediate is compromised, its authorization has to be withdrawn and every identity it vouched for replaced, following whatever policy the verifier enforces. Root trust needs its own response, because the anchor lives in trust stores you may not control.

Accept the design with four concrete cases: an eligible device enrolls, an unapproved request is refused, an operator who has been removed can no longer issue, and an issuer that has been retired no longer grants access. Those four results are the runbook.