CSR Alone Is Not Enrollment: What a VPN CA Must Check

A certificate signing request carries a public key and a requested subject, signed with the matching private key. That signature proves the requester holds the key. It does not prove the requester is entitled to the name, the device or the VPN role being asked for, and treating it as if it did is how a help-desk ticket becomes an access grant.

Two enrollment models are worth comparing by what they bind, not by which protocol they speak.

A Request Asserts a Name, It Does Not Prove One

Read the request for what it actually contains: a public key, a subject the requester chose, and a self-signature over both. Nothing in that structure references your inventory, your account directory or your approval workflow. A subject of cn=finance-laptop is a string somebody typed. Until the issuing process checks that string against a record it trusts, the certificate is an assertion with a signature attached. That distinction is the entire reason an enrollment process exists.

The corollary matters operationally. A certificate authority never needs the client's private key to issue a certificate, and a workflow that asks for one has confused signing with key escrow. Keep generation on the endpoint and send only the public half.

Compare the Models by What They Bind

Manual signing binds whatever the operator remembers to check. An automated enrollment service binds an authenticated request to a decision the service can enforce, and RFC 7030 describes one such design where the client authenticates before a certificate is returned. The difference that survives an audit is not automation; it is whether the identity check happens inside the issuing path or beside it.

Either model still has to answer the same three questions. Who is asking, on which device or role, and for how long. A ticketing system that records the answers is doing real work; a queue where someone eyeballs a common name is not, no matter how carefully the certificate is later formatted.

Pick the model by the number of enrolments you expect and the turnover of devices. A handful of servers a year can survive manual review with a written checklist. A fleet of laptops cannot.

Record the Lifecycle From the First Issuance

Store the certificate identifier, the owner, the intended use, the expiry and the removal path at the moment of issue, not at the first incident. The intended use belongs in the certificate itself through an extended key usage, and the record should agree with it. A certificate minted for client authentication should not be indistinguishable from one for a server.

Plan renewal and lost-device revocation before you issue the tenth profile. A certificate shared across a department turns a targeted removal into an outage, and that decision is much cheaper to revisit now than during a Friday incident.

Verify the Issued Certificate, Then the Access

After enrollment, inspect what was issued and confirm it chains to the authority you expect. Two commands cover the common mistakes: a certificate with the wrong usage, and a chain that only works because the client is configured to ignore validation.

openssl req -in client.csr -noout -verify -subject
openssl x509 -in client.crt -noout -subject -issuer -dates -ext extendedKeyUsage
openssl verify -CAfile ca.crt client.crt

Then test the access rather than the artifact. A certificate establishes identity, and the policy still decides which services that identity may reach. Check both, because a correct artifact paired with an over-broad policy still fails a review. Confirm the client authenticates and receives only the intended routes or resources. Note what you observed, not what the profile was supposed to do.

A profile that works for the wrong reason, such as a matching common name and no identity check, will keep working after the control you thought you had is removed.