为 OpenVPN 对端使用现有的企业 CA

OpenVPN 中没有任何规定要求证书必须来自 Easy-RSA，而已经拥有组织级 PKI 的机群通常不应再建第二套。真正的工作不是选工具，而是决定所签发身份的含义、隧道接受哪些对端，以及续期和吊销如何到达验证方。请按顺序走完下面五个步骤，因为后面的步骤无法修复第一步中做出的角色决定。

签发两个角色，而不是一个共享身份

每个对端都需要自己的证书和匹配的私钥。请 PKI 团队签发带有服务器用途的服务器身份，以及带有客户端用途的独立客户端身份，好让隧道在握手时能区分两者。

顶住截止日期压力下出现的捷径。把 Web 服务器密钥复制到笔记本电脑，会抹掉角色检查所依赖的区分；把 CA 签名密钥装在 VPN 终端上，则会让一台被攻陷的主机变成被攻陷的层级。PKCS12 包可以携带终端密钥及其证书链，但它从不授予在另一个角色中复用该身份的许可。

在每一侧接好信任输入

客户端和服务器各自都需要一个信任锚、自己的身份以及明确的角色预期。声明这三项的客户端片段如下所示。

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

服务器侧用 remote-cert-tls client 和自身证书来镜像这一点，这正是阻止客户端证书被当作服务器接受的关键。名称检查是与角色检查相互独立的决定。请阅读已部署的配置，确认比较的是哪个字段，而不要假定为浏览器式的主机名匹配。两侧还应明确说明自己信任哪个签发者，因为机群范围内共享的文件路径并不等于共享的策略。

交付中间证书，但不扩大信任

两侧不必共享同一条签发链。当对端出示由中间证书签发的证书时，验证方需要该中间证书可用，而 OpenVPN 区分信任锚输入与用于补全本地出示链的额外证书。OpenVPN 2.6 的 TLS 选项参考 对两者都有说明。

中间 CA 本身不是问题，把宽泛的企业根证书丢进信任包才是问题。锚越宽，能通过链验证的证书就越多，而角色检查并不会把它变成授权人员名单。在层级允许时，把锚收窄到真正签发 VPN 身份的那个签发者。若不允许，就把更宽的锚明确记录为有意接受的风险，而不是默认保留。

与 PKI 团队约定续期和吊销如何到达 VPN 验证方，包括哪些签发者重要、由谁发布列表。证书里内嵌的 CRL 分发点只是指令，并不能证明有谁去获取过它。

决定吊销究竟如何到达

crl-verify 让验证方去查询文件或端点，而这种安排需要负责人和刷新路径。部署时只复制一次的列表，会在第一次吊销证书时悄悄失去保护作用。

写下预期的传播时间，并用一张你愿意吊销的证书去测试。如果列表无法在 VPN 主机上刷新，替代方案是更短的有效期加上真正会运行的续期流程，而不是因为存在 URL 就假定吊销有效。

用真实客户端证明接受

连接一个应当被允许的客户端，并在日志中确认协商出的证书细节。然后尝试必须失败的用例：把客户端证书当作服务器出示、来自信任锚之外的签发者的证书，以及若有富余则吊销一张证书。

把接受的签发者、角色检查和吊销来源记录在配置档旁边。当上个月还能用的设备突然连不上时，下一位工程师需要的正是这份记录；它也是企业 CA 在已记录的接受边界内使用、而非被当作通用信任倾倒场的证据。