I am making a CA that I hope to be able to sign RSA and Elliptic Curve-capable (EC) keys with. I was wondering if the best approach was:

  1. CA with RSA keys capable of signing RSA and EC CSRs
  2. CA with EC keys capable of signing RSA and EC CSRs
  3. 2 CA key sets (one RSA, one EC) each signing CSRs of their respective type
  4. 2 separate CAs

I'm using openssl to do this.

Any ideas or recommendations are greatly appreciated, thanks!

  • I'm curious - ECC is quite different than RSA and not as widely adopted. Certicom owns the patents to several aspects of ECC. I haven't play around with ECC much but I recall it's a more efficient asymmetric crypto algorithm. What are you trying to accomplish?
    – bangdang
    Commented Apr 26, 2012 at 21:08
  • I am making an SSL server, but ultimately want to migrate to using EC cryptography instead of just RSA. (ECC is a server requirement, but RSA is acceptable in the interim.) I wanted to make a CA that would be able to handle both RSA and EC client certificate requests, but didn't know if there were any restrictions on what CA's are capable of signing, or what is the most efficient way to set it up. Commented Apr 27, 2012 at 1:01
  • Option 4 is your best bet from an inter-operability standpoint, especially if you're planning to roll out production ssl certs. There are hybrid certs in the wild as well as a few public CA's (entrust being one of them) offering ecc certs but it's still hugely experimental. I know RedHat's CA offers broader support for EC signed certs. My $0.02
    – bangdang
    Commented Apr 27, 2012 at 2:58
  • google has EC certificate signed with sha1-rsa serverfault.com/a/558322/201011 Commented Nov 29, 2013 at 21:52

7 Answers 7


In X.509, a CA can use any signature algorithm, regardless of the type of key in the signed certificates. Theoretically, if both the CA and the signed certificate use DSA keys or EC keys, and the two keys share the same group parameters (i.e. work over the same curve, for EC keys), then the designation of the curve might be omitted in the signed certificate. For EC keys, this may save perhaps a dozen bytes, and PKIX (the group responsible for the Internet X.509 Profile) explicitly forbids this "optimization". Hence I confidently state that there is no link between the types of keys in a CA certificate and the certificates that CA issues.

EC support in the existing deployed software based can be described as "flaky". Although X9.62 specifies how to encode parameters for EC keys in quite arbitrary curves, almost everybody implements only a limited set of "known curves", mostly from the 15 curves from FIPS 186-3. Actually, among these 15 curves, only two of them (P-256 and P-384) have non-anecdotic support in existing browsers. These two curves are the "bare minimum" of EC support as per NSA "suite B" (a recommendation from NSA for non-NSA people -- what constitutes "suite A" is not publicly known).

Also, X9.62 defines quite clearly how an ECDSA signature should be computed for every combination of hash function and curve (i.e. how hash values should be truncated or expanded to fit the curve group order). As could be expected, implementers got it wrong, and many believe that with P-256 (respectively P-384) only SHA-256 (respectively SHA-384) may be used. Therefore, if you use any other hash function, you will run in interoperability issues (I mean, more issues than what you will get for merely trying to use an algorithm which was not born in the Disco era).

The bright side is that P-256 with SHA-256 is, security-wise, "fine" (I love that word). The dark side is that even with that most supported combination, you will get into issues with old browsers (and there are places which are quite conservative with regards to updates -- at my workplace, the only allowed browser is IE 7 !). So you need a backup plan. Since the backup should be a whole-RSA PKI (RSA everywhere from the root down to the server and user certificates) for compatibility, and you want to ultimately switch to a whole-EC PKI, then you need two roots, one with RSA and one with EC. You can smooth out transitions to some extent with cross-certificates, but it is a whole can of worms.


Tom's answer is correct for X.509 standard and many browsers which are based on standard SSL libraries support the case. However, in this rough real world, I found some devices rejecting ECDSA certificate which has RSA signatures, with TLS 1.2 negotiation.

I think the reason is that the authors of the devices followed the RFC-4492, (** is mine)

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.

though RFC-5246, TLS1.2, loosened this restriction. (** is mine):

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

So be warned that such a device exists.


According to RFC 3280 no constrain is applied to signature algorithms: Subject Public Key Info

This field is used to carry the public key and identify the algorithm with which the key is used (e.g., RSA, DSA, or Diffie-Hellman). The algorithm is identified using the AlgorithmIdentifier structure specified in section The object identifiers for the supported algorithms and the methods for encoding the public key materials (public key and parameters) are specified in [PKIXALGS].

Thus any algorithm specified in RFC 3279 can be used for CA, Subject and CRL signature independently.


No, they don't need to have the same type of key, to the best of my knowledge. As far as I know, the CA's public key does not need to use the same algorithm as the entity whose public key it is signing.

But you should be able to test it pretty readily, and testing with popular browsers is highly recommended.


According to RFC4492 related to Elliptic Curve Cipher Suites:

     Key Exchange Algorithm  Server Certificate Type
      ----------------------  -----------------------

      ECDH_ECDSA              Certificate MUST contain an
                              ECDH-capable public key.  It
                              MUST be signed with ECDSA.

      ECDHE_ECDSA             Certificate MUST contain an
                              ECDSA-capable public key.  It
                              MUST be signed with ECDSA.

      ECDH_RSA                Certificate MUST contain an
                              ECDH-capable public key.  It
                              MUST be signed with RSA.

      ECDHE_RSA               Certificate MUST contain an
                              RSA public key authorized for
                              use in digital signatures.  It
                              MUST be signed with RSA.
  • This answer doesn't address the question. The quote is in reference to a single certificate, note the chain. See answer by @MKSaravanan.
    – bdeem
    Commented Jan 28, 2019 at 19:10

CA signature algorithm can be different from certificate public key algorithm.

For example, a certificate containing ECDSA public key can be signed by the CA using RSA-SHA256.

Here is a real life example from google ECDSA certificate which is signed by the CA using RSA-SHA256.

$ echo | openssl s_client -connect www.google.com:443 -cipher 'ECDHE-ECDSA-CHACHA20-POLY1305' -tls1_2 2>/dev/null| sed -n '/BEGIN/,/END/ p' | openssl x509 -text -noout
        Version: 3 (0x2)
        Serial Number: 3957570017544888113 (0x36ec1cf67d7fdf31)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Google Inc, CN = Google Internet Authority G2
            Not Before: Apr 17 12:48:49 2018 GMT
            Not After : Jul 10 12:38:00 2018 GMT
        Subject: C = US, ST = California, L = Mountain View, O = Google Inc, CN = www.google.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Subject Alternative Name:
            Authority Information Access:
                CA Issuers - URI:http://pki.google.com/GIAG2.crt
                OCSP - URI:http://clients1.google.com/ocsp

            X509v3 Subject Key Identifier:
            X509v3 Basic Constraints: critical
            X509v3 Authority Key Identifier:

            X509v3 Certificate Policies:

            X509v3 CRL Distribution Points:

                Full Name:

    Signature Algorithm: sha256WithRSAEncryption
  • Per RFC4492, Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA key exchange algorithms require the server's certificate to be signed with a particular signature scheme, this specification (following the similar cases of DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in [2] and [3]) does not impose restrictions on signature schemes used elsewhere in the certificate chain.
    – bdeem
    Commented Jan 28, 2019 at 19:07

Long ago (TLS 1.0 or earlier SSL. I don't want to look it up right now but its there in the RFCs) there used to be a requirement that all of the cryptography in the cert chain should be of the same type. But, that went away by I believe TLS 1.1. However, for safety's sake because some implementations may not be able to handle mixed mode cert chains it is a safe practice not to mix and match.

I may be a little cynical but I'd guess that Google mixes up their crypto with ECC leaves and RSA roots because they want to see if they can break things. Then they can lecture anyone who complains that they are a non-compliant ignorant twit who should read the RFC's

  • To be honest, for an old answer you should not write an answer like this.
    – kelalaka
    Commented Feb 26, 2022 at 11:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .