为 VPN 网关与客户端角色设计 AD CS 模板

企业 CA 可以在自身从不充当网关的情况下，签发 VPN 所需的每一张证书。设计工作在于决定每一方必须证明什么，然后判断哪个模板能签发恰好证明这一点的凭据。我先写角色表，复制合适的模板而不是就地修改，按角色固定使用者名称的来源，把结果发布到签发 CA 上，并在任何人自动化之前先登记一个试点。下面每一步都是「CA 明明工作正常，却仍然签出 VPN 会拒绝的证书」的地方。

打开模板控制台之前先写角色表

两个角色，两种用途。网关证明的是服务身份，因此其证书需要 Server Authentication (1.3.6.1.5.5.7.3.1)、包含数字签名与密钥加密的密钥用法，以及客户端拨号使用的主机名（放在使用者替代名称中）。用证书认证的客户端需要 Client Authentication (1.3.6.1.5.5.7.3.2)，以及与网关在对端检查中所期望的相符的身份。用户证书与计算机证书不能互换，因为它们位于不同的存储区，并由不同的进程使用。

为每个角色写下四列：必须出现的身份、用途、密钥的消费者，以及密钥是否允许离开本机。这张表决定了后面每一个复选框，它也是你交给评审者的东西。基于密码的客户端认证是另一条分支：如果网关用凭据认证用户，那么分发客户端证书只会增加工作量，而不会增加任何证明。

复制模板，而不是修改共享模板

从用途大致正确的模板出发，例如网关用 RAS and IAS Server，已加入域的设备用 Computer，然后复制它，并给副本起一个说明用途的名字。扩大其他服务已在使用的模板，正是六周后弄坏不相干东西的那种改动。在副本上，把应用程序策略设为角色表中的用途，保持密钥用法与之一致，选择你的网关接受的密钥算法与长度，并把私钥标记为不可导出，除非某台设备需要导出它才能迁移。

有效期与续订同样属于模板。较短的寿命更容易吊销，却更难运维；较长的寿命减少登记工作量，却延长了密钥泄漏后的暴露时间。选一个你能自圆其说的数字，并注意 CA 自身的有效期与模板的续订期都可能让结果更短。

决定使用者名称从哪来

对于域内计算机或用户，从目录信息构造使用者名称，使申请人无法自行输入名字。对于未加入域的网关，或在 AD 之外分配身份的装置，模板需要改用受控的请求路径。启用申请人自行提供的使用者名称与替代名称是一个真实的决定：它不是允许每个登记人随意主张任何名字的许可，CA 侧的策略仍然必须说明谁可以申请、需要什么证据。

Windows IKEv2 在这里很严格。网关证书会与客户端配置的名称进行匹配，因此 DNS 名称必须出现在客户端查找的位置，通常是使用者替代名称中的 dNSName 条目。为了让不匹配的证书工作而关闭名称检查或用途检查，等于删掉了本可在生产环境中发现不匹配的那道检查。

发布模板，然后收窄权限

在 AD DS 中创建模板对象，与在签发 CA 上发布模板，是两个不同控制台中的两件事。从 Certification Authority 控制台的 Certificate Templates 下发布副本，然后从命令行确认 CA 现在已经提供它：

certutil -CATemplates
certutil -TCAInfo

接下来是权限。只给应当申请的组授予 Read 与 Enroll，不要多给，保持 CA 自身的读取权限不变，并且只在确实打算自动登记、且有让它生效的部署策略支持的地方授予 Autoenroll。模板里的一个复选框本身不会登记任何东西；已发布却没有登记权限的模板，会做出一个列出该证书、随后拒绝申请的入口。

在真实使用者那里登记一个试点

在将要使用它的上下文里申请证书，然后检查返回的内容，而不是相信文件名。用户证书落在当前用户存储区，计算机证书落在本地计算机存储区，MMC 两者都能显示，这正是「成功了」的登记仍可能对 VPN 服务不可见的原因。

certlm.msc
certutil -dump vpn-gateway.cer

读取导出内容中的使用者、替代名称、增强密钥用法与链。对于非 Windows 网关，应通过受支持的工作流提交申请，而不是假定域自动登记能到达它，并确认导出的格式是使用者连同其匹配私钥一起导入的那一种。最后，把信任与授权分开：VPN 仍然要决定哪些用户或设备能到达哪些资源，而吊销只有在网关真的检查吊销时才会移除访问。Microsoft 的证书模板管理指南涵盖了模板控制台、权限以及单独的发布步骤。