Azure Key Vault "Unsupported key size" when importing an RSA certificate if root and intermediate are elliptic curve (EC)

Question

Azure Key Vault "Unsupported key size" when importing an RSA certificate if root and intermediate are elliptic curve (EC)

Martin Himken 106 MVP

I receive an error when importing a certificate to an Azure Key Vault and I'm not sure why. It's probably related to https://github.com/Azure/azure-powershell/issues/9241 somehow. Here's the scenario:

The root is EC all around
The intermediate is EC all around

The following certificate can be imported, but is unfavorably as long as many old applications don't understand v3 certificates (elliptic curves):

The goal however is to import the following certificate, that's using v2 and a RSA2048 private key:

This apparently results in the following error - regardless if tried through PowerShell or GUI (read website):

Is this just not a scenario that has been considered? Is this a bug? It looks a lot like it expects an EC (hence "Supported sizes are [256, 384, 521]") even though its an RSA private key.

Further information:
I stumbled upon this when trying to create a VMMS for Cloud Management Gateway through the ConfigMgr Technical Preview 2009. However, since this seems to be a general issue regarding Azure Key Vault (as the "bad request" shows up in the CloudMgr.log as a response from Azure) I opened this question here. The issue has also been reported to software engineers from ME-CM. There's an additional but non-related issue that the MECM Console crashes right now if the certificate is v3.

JamesTran-MSFT 36,911 Reputation points Microsoft Employee Moderator

2020-09-18T21:09:10.683+00:00

@Martin Himken
Thanks for the detailed post!

Looking at your error message, it does look like it's expecting an EC cert since the message is stating the supported sizes for EC certificates. However, this might be a limitation since you're using an EC (sha384/ECDS) algorithm, with an RSA key, when the supported RSA algorithm would be PS384.

For more info:
Supported key types
Certificate formats of Import we support

If you have any other questions, please let me know.
Thank you for your time and patience!
JamesTran-MSFT 36,911 Reputation points Microsoft Employee Moderator

2020-09-21T16:30:47.263+00:00

@Martin Himken
I just wanted to check in and see if you required additional assistance or if you were able to resolve this issue?
Martin Himken 106 Reputation points MVP

2020-09-21T17:00:31.607+00:00
Hey James,

Thanks for the follow-up. Before I redo my entire CA let me ask the following to make sure I understood correctly:

The issue is related to me using ECDSA where I should’ve used ECDH with P384

The issue is not related to using mixed certificate versions e.g. v3 Root, v3 Intermediate and v2 Webserver auth. This is important! That was the goal.

To heal the situation I would need to ensure every certificate in the chain uses a supported algorithm

The issue is only related to the import functions (GUI and PowerShell alike) not to the key vault not being able to handle the certificate itself. I know this since creating a CSR and signing it manually I can successfully merge the CSR with the cert. If I export and try to import the exact certificate it fails again due to said limitations

The only solution I see out of this would be redoing the CA from scratch with ECDH and p384 - which is a viable thing to me as this is a new pre-prod. Is that about right?
Jason Sandys 31,406 Reputation points Microsoft Employee Moderator

2020-09-21T17:10:52.077+00:00

I don't know the answer to this final question but one point that struck me with the initial question here is that certificate template version and certificate version are two different and unrelated things. Thus, if your cert shows v3, that in no way means that a v3 template was used to create it (and vice-versa).
Martin Himken 106 Reputation points MVP

2020-09-21T17:22:29.897+00:00
Well I can elaborate on this:

The final certificate is supposed to be a webserver certificate which - basically everywhere I need it - is supposed to be build with a compatibility level of “Server 2003”, not 2008 or higher

iirc this results in a v2 cert as it would only be allowed to use CSP (or “legacy”) not KSP

This in turn would only allow for RSA (well at least if I’m aiming for max compat/security)

I might be able to get away with ECDH, but I’d like to explore the possibility of using an RSA before I need to test if internal web applications or rather their clients still accept the cert.
Jason Sandys 31,406 Reputation points Microsoft Employee Moderator

2020-09-21T17:58:11.49+00:00

iirc this results in a v2 cert as it would only be allowed to use CSP (or “legacy”) not KSP

This is the part that is incorrect. KSP usage means a v3 template must be used. As noted, though, this is not tied to the actual certificate version. They (template and certificate versions) are different and independent from one another.

I am in no way saying this is specifically your issue or tied to your issue, but I wanted to call this out as it is a common mistake.
Martin Himken 106 Reputation points MVP

2020-09-21T19:24:47.907+00:00

Gotcha, so that’s determined when the cert is created I assume. The template only gives you the options available when you request it.

Well if I need to redo the CA that will take until Friday when I have the time to do it.

Really appreciate your answers so far. Thank you.

Regards
Martin

Accepted answer

0 additional answers

Your answer

JamesTran-MSFT 36,911 Reputation points Microsoft Employee Moderator

2020-09-18T21:09:10.683+00:00

@Martin Himken
Thanks for the detailed post!

Looking at your error message, it does look like it's expecting an EC cert since the message is stating the supported sizes for EC certificates. However, this might be a limitation since you're using an EC (sha384/ECDS) algorithm, with an RSA key, when the supported RSA algorithm would be PS384.

For more info:
Supported key types
Certificate formats of Import we support

If you have any other questions, please let me know.
Thank you for your time and patience!
JamesTran-MSFT 36,911 Reputation points Microsoft Employee Moderator

2020-09-21T16:30:47.263+00:00

@Martin Himken
I just wanted to check in and see if you required additional assistance or if you were able to resolve this issue?
Martin Himken 106 Reputation points MVP

2020-09-21T17:00:31.607+00:00

Hey James,

Thanks for the follow-up. Before I redo my entire CA let me ask the following to make sure I understood correctly:

The issue is related to me using ECDSA where I should’ve used ECDH with P384

The issue is not related to using mixed certificate versions e.g. v3 Root, v3 Intermediate and v2 Webserver auth. This is important! That was the goal.

To heal the situation I would need to ensure every certificate in the chain uses a supported algorithm

The issue is only related to the import functions (GUI and PowerShell alike) not to the key vault not being able to handle the certificate itself. I know this since creating a CSR and signing it manually I can successfully merge the CSR with the cert. If I export and try to import the exact certificate it fails again due to said limitations

The only solution I see out of this would be redoing the CA from scratch with ECDH and p384 - which is a viable thing to me as this is a new pre-prod. Is that about right?
Jason Sandys 31,406 Reputation points Microsoft Employee Moderator

2020-09-21T17:10:52.077+00:00

I don't know the answer to this final question but one point that struck me with the initial question here is that certificate template version and certificate version are two different and unrelated things. Thus, if your cert shows v3, that in no way means that a v3 template was used to create it (and vice-versa).
Martin Himken 106 Reputation points MVP

2020-09-21T17:22:29.897+00:00

Well I can elaborate on this:

The final certificate is supposed to be a webserver certificate which - basically everywhere I need it - is supposed to be build with a compatibility level of “Server 2003”, not 2008 or higher

iirc this results in a v2 cert as it would only be allowed to use CSP (or “legacy”) not KSP

This in turn would only allow for RSA (well at least if I’m aiming for max compat/security)

I might be able to get away with ECDH, but I’d like to explore the possibility of using an RSA before I need to test if internal web applications or rather their clients still accept the cert.
Jason Sandys 31,406 Reputation points Microsoft Employee Moderator

2020-09-21T17:58:11.49+00:00

iirc this results in a v2 cert as it would only be allowed to use CSP (or “legacy”) not KSP

This is the part that is incorrect. KSP usage means a v3 template must be used. As noted, though, this is not tied to the actual certificate version. They (template and certificate versions) are different and independent from one another.

I am in no way saying this is specifically your issue or tied to your issue, but I wanted to call this out as it is a common mistake.
Martin Himken 106 Reputation points MVP

2020-09-21T19:24:47.907+00:00

Gotcha, so that’s determined when the cert is created I assume. The template only gives you the options available when you request it.

Well if I need to redo the CA that will take until Friday when I have the time to do it.

Really appreciate your answers so far. Thank you.

Regards
Martin

Answer 1

Martin Himken 106 MVP

Ok, I was able to do it today. The following certificate can be uploaded successfully. Redoing the CA and retracting my steps and recreating all certificates was a pain, but apparently worth it. Apparently I selected the wrong algo somewhere down the setup. These are the exact same certificate templates, these were not touched. Seems I somewhere configured ECDSA to be the default instead of ECDH.

Root now looks like this:

And SubCA like this:

So as long as the customers didn't do the same mistakes I did (wherever these were made), this works.

Additional Info:

Root CA and Sub CA Registry Info 1+2 (EncryptionCSP and CSP) - however according to the registry backup these are the same as before
The template now has the following settings available (where it only had ECDSA before)

Only issue that still remains, but is unrelated to key vault is the MEMCM Console crashing when using an ECDH_P384.

This topic should be answered with this. Thanks for your support.

Amandayou-MSFT 11,156 Reputation points

2020-09-25T09:45:46.993+00:00

Hi,

Thank you very much for the update and we're glad the problem is solved now. If you have any questions in future, we warmly welcome you to post in this forum again.

Have a nice day!

Regards,
Amanda
Yue Shi 0 Reputation points

2023-08-23T22:39:46.72+00:00

I've faced the same issue and fixed it by changing the CSR form RSA to ECC. However, it'd be great if someone could help me to understand the relationship between the "Signature algorithm" and "Public key". I understand that the "Signature algorithm" is the algorithm CA uses to sign the CSR and the "Public key" is the public key of the final certification. CA can use any appropriate signing algorithm to sign a RSA or ECC certificate. Why does AKV check the "Public key" size on the "Signature algorithm"?

Share via

Azure Key Vault "Unsupported key size" when importing an RSA certificate if root and intermediate are elliptic curve (EC)

0 additional answers

Your answer