正确的 VPN 密码无法替代缺失的证书

凭据是正确的，配置文件也能顺利导入，但连接仍然在身份验证完成之前失败。在 Windows 上，提示可能是错误 798，指找不到用于 EAP 方法的证书。在 OpenVPN 上，客户端日志显示一次始终无法让服务器满意的 TLS 握手。两者描述的是同一个缺失对象：客户端本应出示的客户端证书。

密码证明知道某个秘密；证书证明持有某把密钥，两者不能互相替代。

密码从来不是问题所在

错误 798 是证书查找失败。客户端被要求提供与所配置身份验证方法匹配的证书，它搜索了自己的存储，没有找到任何可用的东西。这可能意味着证书不存在、存在但没有私钥、已过期，或者存放在查找不到的位置。重试密码无法改变其中任何一种情况，所以即使凭据正确，错误仍会再次出现。

在采取行动之前先读提示。凭据被拒绝、证书查找失败和 TLS 握手失败是三种不同的结果，只有一种与密码有关。

客户端存储必须包含什么

涉及两个对象。客户端证书必须为运行 VPN 客户端的用户安装，并带有其私钥，同时签发根必须受信任。.cer 文件只包含公开证书，因此它本身无法验证任何东西。在 Windows 证书管理器中，客户端身份属于当前用户的个人存储，而根属于受信任的根存储。

把身份安装到计算机存储或仅安装到根存储，都无法满足针对用户个人存储的查找。请一并检查存储、私钥标记和有效期，然后重启客户端，让它重新读取存储。

两个产品，同一个缺失的凭据

OpenVPN 服务器默认要求客户端证书。向客户端添加 auth-user-pass 会发送用户名和密码，而 TLS 握手仍然要求证书，因此在 verify-client-cert require 下，仅凭密码无法完成连接。可以把服务器设置为不要求任何证书，这会使密码成为客户端唯一的凭据，也是真正的强度下降。在 auth-user-pass-verify 后面放一个 shell 脚本可以校验凭据，但这需要启用脚本执行，因此比正规的身份验证后端风险更高。

仅依赖密码的配置文件还取决于推送的选项，而后者又取决于拉取机制是否启用。

不要通过关闭检查来修复缺失的证书

诱人的做法是放宽验证，让提示消失。这去掉了本来在起作用的控制，留下的连接不再能证明它所声称的东西。如果网关最近更换了根，请重新下载客户端程序包，而不是编辑配置文件，因为旧程序包可能仍带有原来的根。如果配置文件编辑器中缺少证书身份验证选项，可能是已安装的 Windows 版本没有提供该方法；请更新系统，而不是手动编辑 XML。

记录证书位于哪个存储、哪个用户运行了客户端，以及私钥是否存在。这三点几乎能解释这类失败的每一种情形。

密码没有问题。该方法真正需要的凭据在别处。