openssl dhparam -check 验证了什么，又漏掉了什么

通过 dhparam -check 让人觉得 VPN 的 Diffie-Hellman 配置已经尘埃落定。事实并非如此。该命令只是把一个参数文件与它声称满足的算术做比对，既不说明组大小是否符合你的策略，也不说明隧道是否真的加载了那个文件。把它当作安全审查，才是首先应当纠正的假设。

参数文件里是一个素数和一个生成元。合法性是这些数字本身的性质，而强度则是对威胁模型与对端的判断，两者不可互换。

合法性检查真正确认了什么

对现有文件运行检查并读取回复。openssl dhparam -in dh.pem -check -noout 会执行参数检查并抑制编码输出。提示参数看起来没问题，只意味着取值在结构上自洽；它并不意味着短组在你的环境中可以接受。

不带 -dsaparam 生成会得到安全素数，此时 (p-1)/2 也是素数，这正是它耗时如此之久的原因。DSA 风格的路径构建参数更快，并会转换为 DH 形式，OpenSSL 手册对这种用法附加了关于全新密钥的额外要求。两种构造都不是会话秘密：该文件是公开的配置材料，既不是证书私钥，也不是控制通道的共享秘密。

先读大小与生成元，再判断文件

知道验证了什么，合法性结果才更有意义。用 openssl dhparam -in dh.pem -text -noout 打印参数，然后记录素数的长度和生成元的取值。

把这个长度与书面策略比较，而不是与习惯比较。如果你的要求是来自现代 TLS 栈的已批准命名组，那么手工生成的文件可能完全是错误的产物。把两个数字都写进变更记录，下一位审查者就不必重新推导。

不要把查看变成重新生成

这里的失效模式是一条看起来像检查、实际却像生成器的命令。附加比特长度，如 openssl dhparam -check 2048，会请求新参数并忽略输入文件。生成元选项也可能如此。如果只想查看，就传入 -in 和 -check，不要加任何描述大小的参数。

把输出写回原路径同样值得警惕，因为手册提醒文件输出不是原子操作。写入中途崩溃会留下被截断的参数文件和一个无法启动的服务。

让组与协议匹配，而不是与潮流匹配

大小策略是工具无法替你读取的决定。2048 位的有限域组是常见的下限，更大的组要付出握手时间，所以选一个你自己基线里写明的数字并记录下来。广泛使用的组不会因为公开而变弱；隐匿在这里毫无增益。

在栈支持已批准命名组的地方，遵循那套有文档的安排，而不是生成古怪参数来显得独特。命名组是对端能够识别、审查者能够查证的东西，这比一个谁都无法归类的定制文件更有价值。

确认 VPN 真的加载了该文件

没有任何进程读取的正确参数文件不会带来任何改变。在 OpenVPN 中，服务端指令是带路径的 dh，而依赖 ECDH 或 TLS 1.3 密钥交换的部署可以改为设置 dh none。要检查正在运行的配置而不是模板，然后确认客户端与对端协商的是同一构造。

用真正需要的证据闭环：隧道协商出的组、文件中的参数长度，以及该长度所满足的策略条款。通过的检查只是那份清单里的一项。把它当成全部答案，正是短组能躲过本该抓住它的审计的原因。