单凭 CSR 不等于注册：VPN CA 必须核验什么

证书签名请求包含一个公钥和一个请求的 subject，并用对应的私钥签署。该签名证明请求者持有密钥，却不能证明请求者有权获得所请求的名称、设备或 VPN 角色。把它当成已经证明了这一点，正是一张服务台工单变成访问授权的开始。

两种注册模型值得按各自绑定什么来比较，而不是按它们讲什么协议来比较。

请求只是声明名称，并不证明名称

从请求实际包含的内容来读它：一个公钥、一个由请求者自行选择的 subject，以及覆盖两者的自签名。这一结构里没有任何东西引用你的资产清单、账户目录或审批流程。像 cn=finance-laptop 这样的 subject，只是某个人敲进去的字符串。在签发流程拿这个字符串去核对它信任的记录之前，证书只是一份附带签名的声明。这一区别正是注册流程存在的全部理由。

其推论在运维上很重要。证书颁发机构签发证书从不需要客户端的私钥，要求提供私钥的流程把签名和密钥托管混为一谈。密钥生成应留在终端，只发送公开的那一半。

按绑定什么来比较两种模型

手工签发绑定的是操作者记得去检查的内容。自动化注册服务把经过身份验证的请求绑定到服务能够执行的判定上，RFC 7030 描述的正是这样一种设计：客户端先完成身份验证，证书才会被返回。经得起审计的差别不在于自动化，而在于身份核验发生在签发路径之内还是旁边。

两种模型仍然必须回答同样的三个问题。谁在请求、在哪台设备或哪个角色上、有效多久。把答案记录下来的工单系统在做实事，只靠某个人盯一眼通用名称的队列则没有，无论事后把证书格式排得多整齐。

按预期注册数量和设备更替速度来选择模型。一年几台服务器，靠一份书面清单做人工复核就够。成批的笔记本电脑则不行。

从首次签发起记录生命周期

在签发那一刻就记录证书标识、所有者、预期用途、有效期和移除路径，而不是等到第一次事故。预期用途应通过扩展密钥用途写进证书本身，记录也要与之相符。为客户端认证签发的证书，不应与为服务器签发的证书无法区分。

在签发第十个配置文件之前，先规划好续期和丢失设备的吊销。一个在部门内共享的证书会把定点移除变成一次中断，而现在重新审视这个决定，比在周五的事故中处理要便宜得多。

先核验签发的证书，再核验访问

注册完成后，检查签发了什么，并确认它能链到你预期的机构。两条命令覆盖常见错误：用途写错的证书，以及一条只因客户端配置成忽略校验才成立的链。

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

接着要测访问，而不只是测产物。证书确立身份，策略仍然决定这个身份能到达哪些服务。两者都要查，因为产物正确但策略过宽，照样过不了评审。确认客户端完成认证，并且只收到预期的路由或资源。记录你实际观察到的，而不是配置文件本应做到的。

一个靠错误原因工作的配置，比如通用名称对得上却没有身份核验，会在你以为存在的控制被移除之后继续工作。