I have a situation for which I am not sure how to approach it. Basicialy I need to find out if it is possible how to issue ECDSA Certificates with a RSA Root Certificate. Is this possible? and how would I go about it?

This is the situation: Currently there is a single tier PKI with a RSA root. We need a tier 2 PKI with 2 subordinates. The plan is to setup the 2tier PKI next to the single tier and then migrate all the templates. One of the requirements now is however that our PKI should support ECDSA certificates because one of our devices we will start using has the following requirements:

• Datapath encryption: AES256 Counter Mode
• Keying messages encryption: EAS256 GCM Mode
• Web access: AES256 GCM Mode
• Digital Signature: SHA-384, ECDSA-521 for load signature
• Key generation: ECC and ECDH P-384 (secp384r1)
• Web browser supported ciphers: TLS_ECDHE_ECDSA_WITH_AES256_GCM_SHA384 or TLS_ECDHE_ECDSA_WITH_AES128_GCM_SHA256

I have seen a post that seems to ask something in the same direction, however the answers that follow are a bit unclear to me.

  • And what is your question? – Crypt32 Jan 29 at 18:16
  • The question is in the first part. Is it possible to issue ECDSA certificates while the root certificate is not ECDSA (RSA in this case), and if so, how would I go about that? – kevin rennenberg Jan 29 at 18:39

This is actually not uncommon. Just have a look at google.com when forcing ECDSA ciphers:

$ openssl s_client -connect google.com:443 -servername google.com -cipher 'ECDSA' -showcerts
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=*.google.com
   i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
 1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
   i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign

openssl x509 -text on the first certificate (*.google.com) shows that it is as expected an ECC certificate, but that it is signed by an RSA key (sha256WithRSAEncryption):

    Issuer: C=US, O=Google Trust Services, CN=Google Internet Authority G3
    Subject: C=US, ST=California, L=Mountain View, O=Google LLC, CN=*.google.com
    Subject Public Key Info:
        Public Key Algorithm: id-ecPublicKey
            Public-Key: (256 bit)
            ASN1 OID: prime256v1
            NIST CURVE: P-256
Signature Algorithm: sha256WithRSAEncryption

The issuer of this certificate is as shown Google Internet Authority G3 and looking at the details of the second certificate provided by the server shows as expected that it has a RSA public key:

    Issuer: OU=GlobalSign Root CA - R2, O=GlobalSign, CN=GlobalSign
    Subject: C=US, O=Google Trust Services, CN=Google Internet Authority G3
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)

Creating an certificate with an ECC public key signed by a CA certificate with a RSA public key is nothing special: just create a CSR for the certificate with an ECC public key and let it sign by the CA. There is no difference in signing an ECC certificate vs. a RSA certificate.


That should be fine. As @TomLeek says in the answer that you link to:

a CA can use any signature algorithm, regardless of the type of key in the signed certificates.

It's certainly more common for issuing CAs and their roots to use the same signing algorithm, for example, on Entrust's root certificate download page you can see that they have separate PKIs for RSA and ECC:

  • RSA: Root CA G2 with issuing CAs L1K and L1M
  • ECC: Root CA EC1 with issuing CAs L1F and L1J

I think this makes it more efficient for the client to verify, for example for an ECC PKI you only need to specify the domain parameters in the root cert, and therefore save on bandwidth, or for constrained IoT devices with limited code space you only need to support one algorithm.

That said, I don't think anything will prevent you from having a mixed-algorithm PKI.


Try it, it "should just work".

If it doesn't, then feel free to post another question with details of the error you ran into.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.