Unable to upload self-signed pfx client certificate, ECDSA P-384, timeout/connection closed

Question

Hi
I have been trying to upload a self-signed (self-generated) client certificate with ECDSA, P-384 (or P-256) for some time, but I only get failures without even an error message.

• Azure -> Web App "xxx" -> Certificates -> "Bring your own certificate (.pfx)" -> "Add certificate" -> "Upload certificate (.pfx) -> fill form -> Validate okay -> Add
• Notifications. "Adding private key certificate: x.scsp.aixtrusion.de_NG_P384", running
• Error adding private key certificate: Timeout bei der Anforderung. Diagnoseinformationen: Zeitstempel "20240226T094652Z", Abonnement-ID , Nachverfolgungs-ID xxxxxx Anforderungskorrelations-ID xxxxxx
  • translation: "Timeout during request. diagnostic information: timestamp ..., subscription id, tracking id ..., request correlation id ...

The same certificate with RSA 3k works without problems, so, can't be the certificate itself, must be key-related.
MS says that a certificate needs to have at least 2048 bits, which does not make any sense in the context of ECDSA, but does not say that ECDSA is not supported.

When I upload, the task starts, but nothing happens. After some time, the task stops, and looking into activity procotol and the json structure I can find:

{"Code":"InternalServerError","Message":"The underlying connection was closed: An unexpected error occurred on a receive.","Target":null,"Details":[{"Message":"The underlying connection was closed: An unexpected error occurred on a receive."},{"Code":"InternalServerError"},{"ErrorEntity":{"Code":"InternalServerError","Message":"The underlying connection was closed: An unexpected error occurred on a receive."}}],"Innererror":null}

"Das Gateway hat innerhalb des angegebenen Zeitraums keine Antwort von "Microsoft.Web" empfangen." (GatewayTimeout)
(sorry for German, but that is the message I get ...- GatewayTimeout is the important part)

"Failed to upload PFX certificate with thumbprint '...' due to error:
The underlying connection was closed: An unexpected error occurred on a receive."

"Failed to upload PFX certificate with thumbprint '...' due to error:
Store update, insert, or delete statement affected an unexpected number of rows (0). Entities may have been modified or deleted since entities were loaded. See

Answer 1

After some round trips, MS decided the certificate was not valid, and I had to import it into Windows, and export the pfx again. This works, but I can only call it a workaround.

Apparently, RSA and ECDSA certificates are parsed by completely different code paths on Azure import, and therefore, have different requirements. I don't know what the actual requirements in the pfx container for ECDSA are, I can only show the information that openssl gives me when I analyze the working ECDSA container. In comparison to it, the openssl-created ECDSA container that was imported into windows (and does not work on Azure), and the working openssl-created RSA container that does work on Azure. It can be seen that the openssl ECDSA and RSA do not differ in anything but their key type.

WIndows export uses 2000 instead of 2048 iterations, and an index(?) as localKeyId instead of a hash. I can't find any information if this is allowed.

OpenSSL with ECDSA (works in windows, but not Azure):

• MAC: sha1, Iteration 2048
• MAC length: 20, salt length: 8
• PKCS7 Encrypted data: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
  • Certificate bag
    • Bag Attributes
      • localKeyID: 29 49 CA 41 98 C0 21 E7 57 64 34 E3 AF 31 F6 BC 40 DA 62 15
  • Certificate bag
    • Bag Attributes: <No Attributes>
• PKCS7 Data
  • Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
  • Bag Attributes
    • localKeyID: 29 49 CA 41 98 C0 21 E7 57 64 34 E3 AF 31 F6 BC 40 DA 62 15
  • Key Attributes: <No Attributes>

Windows with ECDSA, works in Azure:

• MAC: sha1, Iteration 2000
• MAC length: 20, salt length: 20
• PKCS7 Data
  • Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2000
  • Bag Attributes
    • localKeyID: 01 00 00 00
    • friendlyName: {698FDD0F-8C63-425F-B478-2221DDD76285} Microsoft CSP Name: Microsoft Software Key Storage Provider
  • Key Attributes
    • X509v3 Key Usage: 88
• PKCS7 Encrypted data: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2000
  • Certificate bag
    • Bag Attributes
      • localKeyID: 01 00 00 00

OpenSSL with RSA 3k:

• MAC: sha1, Iteration 2048
• MAC length: 20, salt length: 8
• PKCS7 Encrypted data: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
  • Certificate bag
    • Bag Attributes
      • localKeyID: 80 6B 1F 2A 49 57 20 49 19 BE 14 A6 7C FE 31 11 3D 0F 16 2E
  • Certificate bag
    • Bag Attributes: <No Attributes>
• PKCS7 Data
  • Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
    • Bag Attributes
      • localKeyID: 80 6B 1F 2A 49 57 20 49 19 BE 14 A6 7C FE 31 11 3D 0F 16 2E
    • Key Attributes: <No Attributes>

So, if anyone else has this problem, just use Windows in between. Also solves the Problem of having to use SHA1 and TripleDES ... very up-to-date methods, I would say.

Yours,

Sebastian

[edit: formatting got warped by posting]