RSA 证书能否与 dh none 一起用于 OpenVPN？

这里有一份服务器配置：它在标着 RSA 的证书旁边写着 dh none，还带着一个挥之不去的怀疑——两者中必有一个是错的。并没有错。证书负责签名与认证；密钥交换负责建立共享秘密。这是同一次握手中的两项不同工作，TLS 允许 RSA 证书认证采用临时椭圆曲线协商的握手。

这种混淆通常随一份迁移指南而来。指南要求把 DH 参数文件换成 dh none，读者注意到证书并不是椭圆曲线证书，于是把两件事当成了矛盾。

为什么这两项设置看起来相关

OpenVPN 的旧配置要求 DH 参数文件，是因为有限域 Diffie-Hellman 需要双方都认可的域参数。dh 指令指向那个文件。当部署转向 ECDH 时，参数改由命名曲线提供，文件不再需要，这正是 dh none 所表达的。

证书是另一条轴线。证书携带公钥和签名，用来证明服务器身份，而这个公钥可以是 RSA 或椭圆曲线，与如何协商会话密钥无关。使用 ECDHE 协商密钥、使用 RSA 认证的握手很常见，部署也很广泛。

命名让重叠更糟。椭圆曲线同时出现在 ECDHE 和 ECDSA 套件名中，因此很容易以为任何提到曲线的连接都必须使用曲线证书。事实并非如此。

以 ECDHE-RSA-AES256-GCM-SHA384 为例。第一个标记是密钥交换族：临时椭圆曲线 Diffie-Hellman。第二个是认证族：RSA。其余部分描述记录保护和握手所用的哈希。

ECDHE-ECDSA 套件使用同一密钥交换族，但认证方式不同，因此需要椭圆曲线证书。DHE-RSA 套件使用有限域临时 Diffie-Hellman 加 RSA 认证，它确实需要 DH 参数。

从左到右阅读套件名，把每一部分对应到它的职责。标记拆开之后，问题就从「我的证书是否匹配 dh none」变成「我的服务器是否允许密钥交换不需要 DH 文件的套件」。

dh none 告诉服务器不要加载有限域 DH 参数文件。它并不会禁用认证、证书验证或 TLS 本身。但它要求协商出的密钥交换不需要这些参数，实际中就意味着 ECDHE 套件或 TLS 1.3 握手。

故障恰恰来自这个要求。如果服务器的 TLS 密码策略被限制为 DHE 套件，或者客户端只提供这些套件，删掉参数文件后就没有可用的密钥交换方法，握手就会失败。错误通常出现在控制通道握手阶段，发生在任何用户认证之前。先看密码列表，再怪罪缺失的文件。

在椭圆曲线一侧，曲线由服务器的 TLS 配置选择，OpenVPN 在旧分支上提供了选择曲线的选项。TLS 1.3 在协议内部处理组协商，完全不查阅 DH 文件。

dh none 本身并不是安全性降级。交换的强度取决于实际协商出的曲线和套件，所以下一步是看双方选了什么，而不是看缺失的文件。

提高服务器和客户端的详细程度，读取 OpenVPN 在连接后打印的控制通道行。它会写出 TLS 版本和协商的密码，并报告对端证书的密钥类型。这一行就能回答配置文件只是暗示的问题。

如果显示 TLS 1.2、ECDHE-RSA 套件和 RSA 证书，这个组合正是 dh none 所期望的，无需修复。如果显示 DHE 套件，或没有共同密码的握手失败，修复点在密码策略或客户端能力上，而不在证书上。

测试你打算支持的最旧客户端，因为当前客户端可能协商 TLS 1.3，而较旧的客户端只支持 TLS 1.2 套件。如果最旧客户端没有任何交集，要么放宽允许的套件，要么升级那个端点。

不要为了绕过握手失败而关闭证书验证。失败是在告诉你双方无法就密钥交换达成一致，关闭验证会去掉身份保证，却没有解决协商问题。

检查清单：证书是 RSA 吗，是否允许 ECDHE 套件，日志是否显示该套件，最旧的受支持客户端是否也能协商它？如果四项都是，dh none 就在履行它的职责。