Design AD CS Templates for VPN Gateway and Client Roles

An enterprise CA can issue every certificate a VPN needs without ever being the gateway. The design work is deciding what each peer must prove, then which template can issue a credential that proves exactly that. I start with a role table, duplicate a suitable template rather than editing one in place, fix the subject source per role, publish the result on the issuing CA, and enroll one pilot before anyone automates it. Each step below is a place where a working CA still produces a certificate the VPN will reject.

Write the role table before opening the template console

Two roles, two purposes. The gateway proves a service identity, so its certificate needs Server Authentication (1.3.6.1.5.5.7.3.1), a key usage of digital signature and key encipherment, and the hostname the clients dial in a subject alternative name. Clients that authenticate with certificates need Client Authentication (1.3.6.1.5.5.7.3.2) and an identity that matches what the gateway expects in its peer check. A user certificate and a computer certificate are not interchangeable, because they live in different stores and are used by different processes.

Write down four columns for each role: the identity that must appear, the purpose, the key consumer, and whether the key may leave the machine. That table decides every checkbox later, and it is also what you hand a reviewer. Password-based client authentication is a separate branch: if the gateway authenticates users by credentials, distributing client certificates adds work without adding a proof.

Duplicate a template instead of editing a shared one

Start from a template with roughly the right purpose, such as RAS and IAS Server for the gateway or Computer for domain-joined devices, then duplicate it and give the copy a name that says what it is for. Widening a template that other services already use is the change that breaks something unrelated six weeks later. On the copy, set the application policies to the purpose from the role table, keep the key usage consistent with it, choose the key algorithm and length your gateways accept, and mark the private key non-exportable unless an appliance needs it exported to move it.

Validity and renewal belong to the template as well. A short lifetime is easier to revoke and harder to operate; a long one reduces enrollment work and lengthens the exposure of a leaked key. Pick a number you can defend, and note that the CA's own validity and the template's renewal period can shorten the result.

Decide where the subject comes from

For a domain computer or user, build the subject from directory information so the name cannot be typed by the requester. For a gateway that is not domain-joined, or a device whose identity is assigned outside AD, the template needs a controlled request path instead. Enabling requester-supplied subject and alternative names is a real decision: it is not a licence for every enrollee to claim any name, and the CA-side policy still has to say who may ask and what evidence is required.

Windows IKEv2 is strict here. A gateway certificate is matched against the name the client configured, so the DNS name has to be present where the client looks for it, usually a dNSName entry in the subject alternative name. Turning off name checking or purpose checking to make a mismatched certificate work removes the check that would have caught the mismatch in production.

Publish the template, then narrow permissions

Creating the template object in AD DS and publishing it on the issuing CA are separate operations, done by different consoles. Publish the copy from the Certification Authority console under Certificate Templates, then verify from the command line that the CA now offers it:

certutil -CATemplates
certutil -TCAInfo

Permissions come next. Grant Read and Enroll to the groups that should request it and nothing more, keep the CA's own read access intact, and grant Autoenroll only where automatic enrollment is intended and backed by the deployment policy that makes it work. A template checkbox does not enroll anything on its own, and a published template with no enroll permission produces a portal that lists the certificate and then refuses the request.

Enroll one pilot in the real consumer

Request the certificate in the context that will use it, then inspect what came back instead of trusting the file name. A user certificate lands in the current-user store and a computer certificate in the local-computer store, and MMC shows both, which is why an enrollment that "worked" can still be invisible to the VPN service.

certlm.msc
certutil -dump vpn-gateway.cer

Read the dump for the subject, the alternative names, the enhanced key usage and the chain. For a non-Windows gateway, submit the request through the supported workflow rather than assuming domain autoenrollment reaches it, and confirm the exported format is one that consumer imports together with its matching private key. Finally, keep trust and authorisation apart: the VPN still has to decide which users or devices reach which resources, and revocation only removes access if the gateway checks revocation at all. The Microsoft guide to managing certificate templates covers the template console, permissions and the separate publishing step.