Reputation: 1239

Azure key vault - downloaded certificate not same as imported certificate

I imported the following certificate into Azure keyvault

When I download the cert as pem, the private key is changed

az keyvault secret download --file "./text" --id https://myvault.vault.azure.net/secrets/sample/6d5505d2d0cd4d2285c80dc5a259c61c

I got a different private key.

Why is the private key changing? How can I get the same private key that I had imported?

Upvotes: 0

Answers (2)

dave_thompson_085

Reputation: 38990

Late but -- it's the same key, encoded differently

Your input is

$ openssl asn1parse <63646197.1 -i -dump
    0:d=0  hl=3 l= 135 cons: SEQUENCE
    3:d=1  hl=2 l=   1 prim:  INTEGER           :00
    6:d=1  hl=2 l=  19 cons:  SEQUENCE
    8:d=2  hl=2 l=   7 prim:   OBJECT            :id-ecPublicKey
   17:d=2  hl=2 l=   8 prim:   OBJECT            :prime256v1
   27:d=1  hl=2 l= 109 prim:  OCTET STRING
      0000 - 30 6b 02 01 01 04 20 2a-55 2a 42 77 7f 47 bd 05   0k.... *U*Bw.G..
      0010 - 24 f4 97 44 b8 a2 de 8e-ed d3 ff df df b7 c8 56   $..D...........V
      0020 - 05 38 7e f2 3a 49 8e a1-44 03 42 00 04 79 92 9c   .8~.:I..D.B..y..
      0030 - df f4 a2 ee 14 c2 35 0d-81 7e 6b f6 17 b9 c0 cf   ......5..~k.....
      0040 - 74 bf 97 e3 37 9f 97 3c-88 0c 2d 21 8e 1d 78 f6   t...7..<..-!..x.
      0050 - cf 8e 51 c4 52 7f 0a 09-6d bb cf fc b8 30 64 43   ..Q.R...m....0dC
      0060 - cd 76 4c cc 18 b3 97 9e-9a 19 e8 9c ce            .vL..........

with the per-algorithm data for EC defined by SEC1 and (more conveniently) rfc5915

$ openssl asn1parse <63646197.1 -i -dump -strparse 27
    0:d=0  hl=2 l= 107 cons: SEQUENCE
    2:d=1  hl=2 l=   1 prim:  INTEGER           :01
    5:d=1  hl=2 l=  32 prim:  OCTET STRING
      0000 - 2a 55 2a 42 77 7f 47 bd-05 24 f4 97 44 b8 a2 de   *U*Bw.G..$..D...
      0010 - 8e ed d3 ff df df b7 c8-56 05 38 7e f2 3a 49 8e   ........V.8~.:I.
   39:d=1  hl=2 l=  68 cons:  cont [ 1 ]
   41:d=2  hl=2 l=  66 prim:   BIT STRING
      0000 - 00 04 79 92 9c df f4 a2-ee 14 c2 35 0d 81 7e 6b   ..y........5..~k
      0010 - f6 17 b9 c0 cf 74 bf 97-e3 37 9f 97 3c 88 0c 2d   .....t...7..<..-
      0020 - 21 8e 1d 78 f6 cf 8e 51-c4 52 7f 0a 09 6d bb cf   !..x...Q.R...m..
      0030 - fc b8 30 64 43 cd 76 4c-cc 18 b3 97 9e 9a 19 e8   ..0dC.vL........
      0040 - 9c ce                                             ..

which as you can see does not have the optional context-0-tagged parameters field.

In contrast the output is

$ openssl asn1parse <63646197.2 -i -dump
    0:d=0  hl=3 l= 162 cons: SEQUENCE
    3:d=1  hl=2 l=   1 prim:  INTEGER           :00
    6:d=1  hl=2 l=  19 cons:  SEQUENCE
    8:d=2  hl=2 l=   7 prim:   OBJECT            :id-ecPublicKey
   17:d=2  hl=2 l=   8 prim:   OBJECT            :prime256v1
   27:d=1  hl=2 l= 121 prim:  OCTET STRING
      0000 - 30 77 02 01 01 04 20 2a-55 2a 42 77 7f 47 bd 05   0w.... *U*Bw.G..
      0010 - 24 f4 97 44 b8 a2 de 8e-ed d3 ff df df b7 c8 56   $..D...........V
      0020 - 05 38 7e f2 3a 49 8e a0-0a 06 08 2a 86 48 ce 3d   .8~.:I.....*.H.=
      0030 - 03 01 07 a1 44 03 42 00-04 79 92 9c df f4 a2 ee   ....D.B..y......
      0040 - 14 c2 35 0d 81 7e 6b f6-17 b9 c0 cf 74 bf 97 e3   ..5..~k.....t...
      0050 - 37 9f 97 3c 88 0c 2d 21-8e 1d 78 f6 cf 8e 51 c4   7..<..-!..x...Q.
      0060 - 52 7f 0a 09 6d bb cf fc-b8 30 64 43 cd 76 4c cc   R...m....0dC.vL.
      0070 - 18 b3 97 9e 9a 19 e8 9c-ce                        .........
  150:d=1  hl=2 l=  13 cons:  cont [ 0 ]
  152:d=2  hl=2 l=  11 cons:   SEQUENCE
  154:d=3  hl=2 l=   3 prim:    OBJECT            :X509v3 Key Usage
  159:d=3  hl=2 l=   4 cons:    SET
  161:d=4  hl=2 l=   2 prim:     BIT STRING
      0000 - 00 80                                             ..
$ openssl asn1parse <63646197.2 -i -dump -strparse 27
    0:d=0  hl=2 l= 119 cons: SEQUENCE
    2:d=1  hl=2 l=   1 prim:  INTEGER           :01
    5:d=1  hl=2 l=  32 prim:  OCTET STRING
      0000 - 2a 55 2a 42 77 7f 47 bd-05 24 f4 97 44 b8 a2 de   *U*Bw.G..$..D...
      0010 - 8e ed d3 ff df df b7 c8-56 05 38 7e f2 3a 49 8e   ........V.8~.:I.
   39:d=1  hl=2 l=  10 cons:  cont [ 0 ]
   41:d=2  hl=2 l=   8 prim:   OBJECT            :prime256v1
   51:d=1  hl=2 l=  68 cons:  cont [ 1 ]
   53:d=2  hl=2 l=  66 prim:   BIT STRING
      0000 - 00 04 79 92 9c df f4 a2-ee 14 c2 35 0d 81 7e 6b   ..y........5..~k
      0010 - f6 17 b9 c0 cf 74 bf 97-e3 37 9f 97 3c 88 0c 2d   .....t...7..<..-
      0020 - 21 8e 1d 78 f6 cf 8e 51-c4 52 7f 0a 09 6d bb cf   !..x...Q.R...m..
      0030 - fc b8 30 64 43 cd 76 4c-cc 18 b3 97 9e 9a 19 e8   ..0dC.vL........
      0040 - 9c ce                                             ..

which does have the context-0-tagged parameters field, which is redundant when used within PKCS8 as here; also at the PKCS8 level it has the optional context-0-tagged attributes field containing one attribute with id KeyUsage and value digitalSignature. (OpenSSL displays the actual value field of the BITSTRING encoding, including the first octet which is reserved for 'unused bits' and here 00, so the encoded bits are 80, which is bit#0=digitalSignature.) This is technically redundant because it is already in the cert, but I guess Azure finds it convenient to have a copy here.

The actual key for cryptographic purposes is the curve-id, the private scalar "d" at offset 5 in the SEC1 data, and if present (which it is) the public point "Q" at context-1-tag in the SEC1 data, and you can confirm all three of those are the same in the output as the input.

Upvotes: 0

Joey Cai

Reputation: 20107

According to the az command you provided, you import certificate as azure key vault secret.

If so, the certificate content you sent will be the same as the secret value you get.

As I have test, when I import cert as secret. Then I retrieve the same secret value.

So, try to recreate a new secret and import again.

Upvotes: 0

Azure key vault - downloaded certificate not same as imported certificate

Answers (2)

Related Questions