在 X.509 中，CA 可以使用任何签名算法，而不管签名证书中的密钥类型如何。理论上，如果 CA 和签名证书都使用 DSA 密钥或 EC 密钥，并且这两个密钥共享相同的组参数（即在同一曲线上工作，对于 EC 密钥），那么曲线的指定可以在签署的证书。对于 EC 密钥，这可能会节省十几个字节，而 PKIX（负责Internet X.509 Profile的组织）明确禁止这种“优化”。因此，我自信地声明 CA 证书中的密钥类型与 CA 颁发的证书之间没有联系。

基于现有部署软件的 EC 支持可以说是“不稳定的”。尽管X9.62指定了如何以任意曲线对 EC 密钥的参数进行编码，但几乎每个人都只实现了一组有限的“已知曲线”，主要来自FIPS 186-3的 15 条曲线。实际上，在这 15 条曲线中，只有两条（P-256 和 P-384）在现有浏览器中具有非轶事支持。这两条曲线是 NSA “套件 B” 中 EC 支持的“最低限度”（NSA 对非 NSA 人员的建议——“套件 A”的构成尚不为人所知）。

此外，X9.62 非常清楚地定义了应该如何为散列函数和曲线的每个组合计算 ECDSA 签名（即如何截断或扩展散列值以适应曲线组顺序）。正如所料，实施者弄错了，许多人认为 P-256（分别为 P-384）只能使用 SHA-256（分别为 SHA-384）。因此，如果您使用任何其他哈希函数，您将遇到互操作性问题（我的意思是，比仅仅尝试使用并非在迪斯科时代诞生的算法所得到的问题更多）。

好的一面是带有 SHA-256 的 P-256 在安全方面“很好”（我喜欢这个词）。不利的一面是，即使使用最受支持的组合，您也会遇到旧浏览器的问题（而且有些地方在更新方面非常保守——在我的工作场所，唯一允许的浏览器是 IE 7！）。所以你需要一个备份计划。由于备份应该是一个完整的 RSA PKI（从根到服务器和用户证书的任何地方的 RSA），并且您希望最终切换到一个完整的 EC PKI，那么您需要两个根，一个带有 RSA 和一个与EC。您可以使用交叉证书在一定程度上平滑过渡，但它是一整罐蠕虫。

Tom 的回答对于 X.509 标准是正确的，许多基于标准 SSL 库的浏览器都支持这种情况。然而，在这个粗糙的现实世界中，我发现一些设备拒绝具有 RSA 签名的 ECDSA 证书，并使用 TLS 1.2 协商。

我认为原因是设备的作者遵循 RFC-4492，（** 是我的）

2.2.  ECDHE_ECDSA
In ECDHE_ECDSA, the server's certificate **MUST** contain an ECDSA-
capable public key and **be signed with ECDSA.**

The server sends its ephemeral ECDH public key and a specification of
the corresponding curve in the ServerKeyExchange message.  These
parameters MUST be signed with ECDSA using the private key
corresponding to the public key in the server's Certificate.

虽然 RFC-5246，TLS1.2，放宽了这个限制。（** 是我的）：

7.4.4.  Certificate Request
...
If the client provided a "signature_algorithms" extension, then all
certificates provided by the server MUST be signed by a
hash/signature algorithm pair that appears in that extension. **Note
that this implies that a certificate containing a key for one
signature algorithm MAY be signed using a different signature
algorithm (for instance, an RSA key signed with a DSA key).  This is
a departure from TLS 1.1, which required that the algorithms be the
same.**  Note that this also implies that the DH_DSS, DH_RSA,
ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the
algorithm used to sign the certificate.  Fixed DH certificates MAY be
signed with any hash/signature algorithm pair appearing in the
extension.  The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are
historical.

因此请注意，存在这样的设备。

根据RFC 3280，签名算法没有约束：

4.1.2.7 主题公钥信息

该字段用于携带公钥并标识使用该密钥的算法（例如，RSA、DSA 或 Diffie-Hellman）。该算法使用第 4.1.1.2 节中指定的 AlgorithmIdentifier 结构来标识。[PKIXALGS] 中规定了支持算法的对象标识符和对公钥材料（公钥和参数）进行编码的方法。

因此，RFC 3279 中指定的任何算法都可以独立用于 CA、主题和 CRL 签名。

不，据我所知，它们不需要具有相同类型的密钥。据我所知，CA 的公钥不需要使用与它正在签名的公钥的实体相同的算法。

但是您应该能够很容易地对其进行测试，并且强烈建议使用流行的浏览器进行测试。