为什么插了令牌 OpenVPN 仍然要求私钥文件

你把令牌插上，厂商自己的工具能识别它，VPN 客户端却仍然要求私钥文件。这个提示并不证明令牌不受支持。它通常说明配置从未告诉客户端去用令牌，于是客户端退回默认期望的证书和密钥输入。

要让这次退回停下来，两个彼此独立的值都必须正确：暴露令牌的提供商，以及令牌里证书的身份。它们由不同选项提供，很容易混为一谈。

客户端要求文件，是因为配置这么写着

默认配置期望一个证书文件和一个私钥文件，或者一个 PKCS#12 打包文件。这些输入缺失时，客户端没有东西可加载，表现和文件不存在时几乎一样，所以症状被读成路径损坏，而不是机制缺失。PKCS#11 这条路是替换这些输入，而不是补充它们，因此仍然写着密钥文件的配置会继续使用该文件。请主动移除文件输入，让令牌同时提供两半。

提供商选项指的是中间件库，不是设备，也不是证书。打包好的客户端能否加载该库，取决于它是怎么构建的，其中包括部分构建启用、另一些构建省略的可选 p11-kit 支持。通用教程没法告诉你自己的软件包属于哪种情况。

序列化的身份是另一个值

证书身份是发现过程生成的一长串序列化字符串，它既不是库路径，也不是令牌 PIN，更不是 VPN 账号名。它常含需要加引号的字符，而没加引号的值可能被截断或被误读，却不报明确错误。用客户端自带的身份发现选项列出令牌暴露的内容，然后精确复制目标条目。直接选列表里的第一个对象，正是设备最终出示错误证书的常见原因。

发现输出还能回答一个更靠前的问题：令牌究竟能不能通过这个提供商看到。如果它什么也没列出，问题就在 VPN 客户端之上，属于中间件。

建立连接的进程必须能访问到令牌

在桌面会话里能用的令牌操作，说明不了系统服务的情况。服务可能以另一个用户运行、处在不同的挂载命名空间、模块路径漏掉了厂商库，或者没有打开设备节点的权限。先确认到底是哪个进程持有连接，再从那个上下文去测试。

PIN 的处理值得单独决定。参考实现提供 PIN 缓存和受保护的身份验证路径，两者存在的意义是让运维人员挑一种流程，而不是自己发明。不要把无人值守的需求变成共享配置里的明文 PIN，那等于用令牌的保护换方便。在令牌禁止导出密钥的场合，签名发生在设备上，PIN 就是唯一的本地秘密。请按这一点给予相应的谨慎。

令牌不替代什么

令牌在既定策略下认证客户端，并不替代客户端对服务器的检查。成功选中的证书不等于可以接受意外的网关证书，这两道验证保护的是相反方向。

注册仍然要在签发方完成，网关仍然要授权该身份。

验收时要把阶段分开：提供商加载、找到目标证书、在本地授权下使用私钥、VPN 认证通过、资源操作成功。停在第一个失败的阶段，而不是反复试密码、重装加密栈。

记录版本、模块归属、选定的公开标识符和清理过的错误信息，PIN 和凭据包不要写进这份记录。