OpenSSL 3 之后 OpenVPN 密钥提示：检查 provider

没有人改动过配置文件，可同一个客户端现在每次启动都要私钥口令。如果这个变化出现在发行版升级后的几天内，升级很可能就是原因：OpenSSL 3 重组了算法支持，旧库原本能正常读取的密钥，可能一个字节都没变却变得无法读取。请按顺序逐项检查，因为只看提示的话，其中两项看起来完全一样。

第一个问题是密钥是否加密，第二个问题是这个构建能否解密它。只有两个答案都清楚之后，改配置才有意义。

检查密钥是否加密

先读取文件第一行，再让库去解析它，因为文件名证明不了任何事。带有 ENCRYPTED PRIVATE KEY 标签的 PEM 块是加密的 PKCS#8，而带有 RSA PRIVATE KEY 的旧式 Proc-Type: 4,ENCRYPTED 块属于传统形式，两者都需要口令短语。未加密的 PRIVATE KEY 块则完全不应索要口令。请以拥有该文件的账户运行解析，因为权限问题会给出另一种、远没那么有意思的错误。

如果密钥确实没有加密，客户端却仍然发问，那就别再盯着密码学，而应检查配置文件是否指定了服务仍能读取的 askpass 文件。

检查这个构建能否解密它

OpenSSL 3 把算法支持拆分成多个 provider，一批较旧的密码算法现在位于 legacy provider 而不是默认 provider。用这些算法加密的密钥依然有效，但未加载 legacy provider 的库无法解出它。在某些客户端上，这表现为反复出现的提示；在另一些客户端上，则是输入口令后立刻硬失败。

用同一个二进制把同一把密钥解析两次：第一次只加载默认 provider，第二次在命令行上同时请求 legacy 和默认。如果第二次在第一次失败之处成功，诊断就建立在证据上，而不是升级的时间点。如果两次以完全相同的方式失败，那就是口令短语错误或文件损坏，任何 provider 设置都修不好。

检查范围最小的可用修复

优先选择只作用于客户端的改动，而不是系统级改动。某些 2.6 构建接受一个 profile 选项，能为该守护进程加载两组 provider，所以依赖它之前，请按你所用确切版本的手册核对该指令；直接改系统的 openssl.cnf 则会影响主机上的每个 OpenSSL 程序。更窄的设置也更容易在密钥重新编码后回退。

不要为了消除提示而删掉口令短语。那会把受保护的凭据变成明文文件，并悄悄改变它出现的每一份备份、副本和诊断包的风险。真正重要的区别是：密钥需要它的口令，还是这个库根本无法解密它。

检查服务上下文，然后重新编码

密钥可以解锁之后，用当前算法重新加密它让这项依赖消失。用现代密码写出新文件，确认它能被解析，更新 profile，旧副本只保留到连接成功为止。绝不要把口令短语放在命令行上，本地任何用户都能从进程列表里读到。旧文件要等新文件从服务账户连接成功后再删，只在你的 shell 里成功不算数。

然后检查真正运行客户端的 unit。在你的 shell 里可读的密钥，对以其他账户或加固后的主目录设置运行的服务，可能根本不可读。

把 provider 设置记在 profile 旁边，并把那两条命令的测试一并保留。以后某次升级去掉了 legacy provider 时，重跑该测试，看密钥是否还需要它，或者 profile 能否退出这个临时方案。

提示是一个至少有三类原因的症状，其中只有一类是口令短语缺失。