SECLEVEL=0 只能缓解症状，不能解决证书问题

OpenVPN 连接失败，有人找到一行加上 SECLEVEL=0 的修复，隧道就起来了。改变的既不是证书，也不是密码套件；移动的是整个库的接受阈值，而进程之后做的一切都继承了这个新边界。在把同一行复制到环境中每个配置文件之前，这一点值得弄清。

确定生效的是哪个库和哪条策略

SECLEVEL 是 OpenSSL 的概念，所以第一个问题是你的构建到底用不用 OpenSSL。OpenVPN 可以链接不止一个密码学库，而只对其中一个有意义的设置，对其他的毫无作用。先问二进制文件是用什么构建的，再问库加载了哪个版本和配置：

openvpn --version | head -3
openssl version -a

仔细阅读版本输出，因为发行版会修改默认值。有些发行版提供的系统配置会把最低级别抬高到上游默认值之上，这就是同样的配置在两台装有相同 OpenVPN 软件包的机器上表现不同的原因。生效的策略是运行中的进程所加载的那一份，而不是上游手册里的那一份。

然后分清人们混淆的两个层面。OpenVPN 有自己的 TLS 控制，包括证书配置文件设置和显式密码列表，它们位于库所强加的一切之上。降低库的级别不会改变你的 OpenVPN 配置列出哪些密码，收窄 OpenVPN 列表也不会抬高库的阈值。知道是哪一层拒绝了你，才能让修复不至于停留在猜测。

第一个候选是身份材料：密钥太小的证书，或者签名算法已不被策略接受的证书。第二个是密钥交换参数，例如策略认为太弱的群组。第三个是策略排除的密码套件。三者都可能造成握手失败，而只有错误文本和协商阶段才能把它们区分开。

这三者都不是数据通道的密码。OpenVPN 的隧道加密与 TLS 握手是分开协商的，所以安全级别改动后连接成功，并不能说明保护你数据的密码是什么。如果你真正要问的是数据机密性，那你完全看错了旋钮。

降低级别会同时放宽对三种输入的接受。这正是人们忽略的部分：放行旧证书的修复，也会放行一个弱群组和一个你可能并不打算允许的密码套件。一个错误促成了这次改动，而改动比错误更宽。这种不对称正是有限例外优于全环境默认值的原因。

在动手改配置之前，先保存确切的错误，包括报告它的阶段和它指名的对象。证书问题要通过换成当前策略接受的材料来解决，通常意味着向签发机构重新签发，而不是重装同一个文件。

如果被拒绝的输入属于你无法控制的对端，那么要谈的是对端所有者与受支持的替代材料。为了迁就一个没人维护的系统而降低自己的阈值，是把代价从他们身上转嫁给之后连接的所有人。

在服务器执行策略的地方，先检查是不是 OpenVPN 层面的设置才是真正原因，再怪库。要求比已部署证书能满足的更严格等级的证书配置文件，无论安全级别设成什么都会失败，而移除该配置文件比关闭库的检查是更窄的改动。

有时获批的兼容性例外才是正确答案，尤其是对带有明确退役计划的旧对端。把它限定在需要它的服务上，而不是整台主机：按服务拆分的配置文件或专用的 OpenSSL 配置，比在全局配置里加一条导出影响面更小。

随例外一起写下四件事：确切的设置、批准它的所有者、受影响的客户端，以及撤销条件。没有退役条件的例外，就是附带了临时理由的永久削弱。

回滚应当是你已经测试过的单一步骤。保留先前的配置，应用改动，确认服务启动，并确切知道如果下一次连接表现不同该恢复哪个文件。

连接成功只能证明修改后的条件放行了它。确认主机名和对端校验仍在发挥作用，所用的证书正是你打算部署的那一份，并且协商出的数据通道与你以为的策略相符。

openssl x509 -in /etc/openvpn/client.crt -noout -subject -dates -text | grep -E 'Signature Algorithm|Public-Key'
openvpn --show-tls | head -20

OpenSSL 安全级别参考明确指出，该框架对密钥、签名、群组和套件同时施加限制，而零级允许回调检查的一切。这就是你所改动之事的范围，也是别人问修复是否范围很窄时应当引用的那句话。

经得起审计的交接会说明：哪条策略拒绝了哪个输入、改动了什么、结果还接受什么。„用 SECLEVEL=0 就能工作“只是对一次连接的观察，不是对部署的安全评估。