TL;DR 是的，参数（不是键）可以共享。

首先，不要说“参数键”。参数和键是相关但不同的。参数的全部意义在于它们定义了一个数学组，在该组中选择和使用键。生成参数的成本很高（DH 和 DSA 的成本适中，ECC 的成本更高）；为给定参数生成密钥要便宜得多。此外，DHE 密码套件的一个要点是您的 SSL 实现会为每个连接生成一个新的临时密钥。如果您只运行具有一组固定 DH 参数的服务器，并且该服务器使用 DHE 处理来自一个客户端的多个连接，则您已经在使用具有相同参数的多个密钥。对于 ECDHE 也是如此，但更多内容见下文。

只要参数没有被攻击者选择或影响或以其他方式严重不良，在多台服务器上使用相同的参数对连接安全没有任何损害（增加） ——在这种情况下，它们甚至不应该用于一台服务器。我看到的多个参数的唯一情况是，如果您有一些（可能是虚拟的）服务器必须支持（通常是较旧的）客户端，这些客户端只能处理 DH 1024 位，现在安全裕度相当小，而其他服务器想要更大2048 位或更多的余量 - 和/或符合 NIST 800-57 等标准（如果适用）。

（已添加）一个警告：如果您试图隐藏服务器处于共同管理之下，使用共享但其他独特的参数会提供一个线索，即他们的管理员可能是相同的 - 但不是一个强大的管理员，因为它们可能只是使用相同的软件。例如，很长一段时间以来，Apache 都有一组内置的默认 DHE 参数，在 Snowden 和 Logjam 之前，几乎每个人都使用该默认值而不考虑它，所以所有这些服务器都使用相同的参数（当它们完全使用 DHE 时）即使他们中的大多数是完全不相关和分开的。（类似地，研究人员在网上扫描了常见的RSA模数或因子——即 一个安全漏洞，也是一个非常糟糕的漏洞——已经将其中一些漏洞追溯到特定的硬件或软件产品，没有其他共性。）

对于 ECDHE（以及 ECDHA 和 ECDH 和 ECDSA，尽管这些不是您的问题），有标准参数集（通常称为命名曲线）更易于使用，并且具有更广泛/可靠的互操作性，因此您甚至不应该尝试生成自己的。到目前为止，最好始终使用 P-256 或 P-384，这两条标准曲线（几十条中的一条）被 NSA 在其 Suite B 配置文件中“祝福”。

看到很多重复：

• 在 TLS 服务器中使用相同的 DH 参数有什么影响？
• 有人可以更好地解释一下通过生成 DH 参数究竟完成了什么？
• DHE p 和 g 因子应该多久回收一次？

更新：由于这已被删除，我将在 2016 年补充一点（对于 TLS）rfc7919建议使用标准化参数（对所有用户都相同，由 IKE rfc2412 和 rfc3526 中的“无所事事”方法的变体选择)，而2018 年的TLS 1.3 rfc8446要求对经典/整数/Zp/modp/FFC DHE 和 ECDHE 进行标准化组，在 4492 中删除了无论如何都没有人使用的“显式”EC 选项。（并且 1.3 通常需要 [EC]DHE，因为它放弃了普通 RSA 和静态 [EC]DH 形式的密钥交换，尽管对于少数可管理的情况仍然存在 PSK。）