不重建 CA 也能添加 VPN 客户端

你需要为又一台笔记本再签一张证书，但搜索结果里的第一篇教程一上来就是删除 PKI 目录的命令。那条命令属于首次搭建，不属于登记；一旦执行，你失去的是 CA、签发历史，以及所有信任旧签发者的客户端配置。真正要判断的问题更窄：现有签发者是否仍有可用状态，新设备是否落在你已有的登记策略之内？三个条件决定答案，其中只有一个才够格谈重建。

重建到底毁掉什么

重新初始化 PKI 会把目录换成一套空结构：新的 CA 密钥和证书、空的签发数据库、归零的序列号计数器。客户端不会悄悄跟着变。它们的配置钉住了旧 CA，所以每台已有设备都得重新登记，联系不上的只能上门处理。

更安静的损失是账本。吊销的前提是你知道发过哪些序列号、发给了谁。清空索引后你照样能签名，却再也说不准在用的证书里哪些本来要吊销。一个只有证书、没有对应签发者状态的 CA 目录，是会把系统错的那一半恢复回来的备份。

把 CA 私钥复制到运行中的服务器旁边，是另一种应当拒绝的捷径：它把本该离线保管的签名权威变成一台处理不受信任流量的主机上的又一个文件。

条件一：签发者状态还能拿到吗

先找到服务器真正信任的那个目录。把服务器作为 CA 出示的证书与 PKI 目录里的证书按指纹比对，而不是按文件名：

openssl x509 -in ca.crt -noout -fingerprint -sha256
openssl x509 -in /etc/openvpn/ca.crt -noout -fingerprint -sha256

指纹一致，说明登记是增量的，什么都不用重建。指纹不同，你就是在用服务器不信任的 CA 签名：证书装得上，握手却失败，而这个错误常被当成客户端故障排查好几个小时。

然后再找签发状态：索引文件、序列号计数器和 CRL 编号文件。索引没了但私钥还在，你仍可签发，却继承了吊销记录的问题。把它写进变更记录，而不是盖过去，因为下一次吊销请求就会把它翻出来。

条件二：新的私钥在谁手里

这是用户能感受到的决定，所以要明确。在客户端生成、以请求形式提交的密钥，从第一条命令起私钥部分就留在设备上，管理员从不经手。由服务器生成的密钥对没有工具的旧设备更省事，却让管理员成了每把密钥的保管人，也让服务器被攻破的后果更大。

面对已有 CA 使用 Easy-RSA 3，导入并签署一个请求只需两条命令：

./easyrsa import-req /tmp/alice.req alice
./easyrsa sign-req client alice

证书类型要刻意选择。签发成服务器证书而不是客户端证书，文件看起来没问题，对端却会拒绝，错误信息几乎不解释原因。若用 openssl ca 签名，同样的选择藏在你要传的扩展里，而不在你继承的默认段里。

条件三：服务器要的不止一张证书吗

对使用证书认证的普通 OpenVPN 服务器来说，证书本身就是登记：通用名成为客户端身份，按客户端的目录、推送路由或固定地址都挂在这个名字上。只加证书却忘了对应配置，隧道能连上，用户需要的路由却永远不出现。

平台会改变这一点。OpenVPN Access Server 有自己的用户库，签好的证书并不等于账号；账号必须存在且被允许。另一些网关把身份串映射到组。登记一台设备通常要碰两套系统，证书只是第一套。

增量流程，以及什么情况下重建才正确

不造成连带损害的流程是：按指纹确认签发者，给 PKI 目录做一份新备份，为客户端角色导入并签署请求，通过批准渠道交付证书及证书链，然后在用户连接之前完成校验：

openssl verify -CAfile ca.crt alice.crt
openssl x509 -in alice.crt -noout -subject -issuer -dates -purpose

用途一行应当显示 SSL client。最后要在签发之后更新 CA 备份，因为在新序列号写入之前留下的备份，恢复出来的是没有你刚加那台设备的状态。

重建只在三种情况下正确：CA 私钥已被攻破、签发状态不可挽回地丢失，或者你有意更换密钥算法或证书策略。这三种都是需要为每台客户端安排重新登记的工程，不是一次单机申请里的步骤。都不成立，就做增量登记，别动现有签发者。