I am using openssl commands to create a CSR with elliptic curve secp384r1 and hash signed with algorithm sha384:
openssl ecparam -out ec_client_key.pem -name secp384r1 -genkey
openssl req -new -key ec_client_key.pem -out ec_clientReq.pem
Then I display the CSR in readable format with this command:
openssl req -in ec_clientReq.pem -noout -text
In the signature part of the CSR I get this:
Signature Algorithm: ecdsa-with-SHA1 30:64:02:30:06:a1:f2:5e:1b:34:18:b9:f3:7c:e9:52:c8:78: 99:90:63:d2:1e:d2:f5:7a:25:f3:d6:4d:6d:90:d0:bf:25:45: 15:ad:aa:17:34:ad:1a:b9:1e:67:2b:cf:d7:a6:9b:e5:02:30: 31:fe:76:37:4b:11:3a:e7:2d:63:52:bb:18:2f:8e:43:a7:bb: 65:74:38:a4:92:38:9d:eb:ec:22:8f:77:f3:e4:5f:47:2d:f8: 2a:9b:e1:2c:ba:a7:b0:e6:c2:54:8d:0e
What should I do in order to get a signature algorithm "ecdsa-with-SHA384" instead of "ecdsa-with-SHA1"? Am I missing something in this process? I tried to use -sha384 in the second command
openssl req -new -key ec_client_key.pem -out ec_clientReq.pem -sha384
but I got the same result regarding the Signature Algorithm
Signature Algorithm: ecdsa-with-SHA1 30:65:02:30:4e:b4:b6:5f:3a:fc:b7:28:e5:4b:f0:3d:9a:ea: 4a:ba:ce:a4:f1:a6:e8:cd:15:19:23:a6:81:3f:24:01:d7:81: 3c:9d:9a:4c:cd:4b:4a:12:6d:69:48:ec:7e:73:7d:73:02:31: 00:d7:a5:63:9b:21:b2:95:ce:7f:13:3f:c5:1a:ac:99:01:ff: ba:9c:59:93:d5:ee:97:03:b5:9e:c1:7d:03:f8:72:90:65:b5: 08:7c:79:ae:ea:4f:6e:b0:2b:55:1a:11:a5
Another question regards the format of the signature. In the examples above one is 102 bytes long and the second one is 103 bytes long. It seems that the first bytes are an header including type, length and may be some other stuff like padding. But I cannot find an exact definition. Can someboby put some light on this? Thanks
I tried again with last openssl version 1.0.1e this time (instead of 0.9.8n).
openssl ecparam -out ec_client_key.pem -name secp384r1 -gen
openssl req -config openssl.cnf -new -key ec_client_key.pem -out ec_clientReq.pem -sha384
openssl req -in ec_clientReq.pem -noout -text
Now I get the expected result:
Signature Algorithm: ecdsa-with-SHA384
It looks that version 0.9.8n does not support sha384.
This extract from the CHANGES file seems to confirm this:
Changes between 1.0.0h and 1.0.1 [14 Mar 2012] : ... *) Add HMAC ECC ciphersuites from RFC5289. Include SHA384 PRF support. As required by RFC5289 these ciphersuites cannot be used if for versions of TLS earlier than 1.2. [Steve Henson]
Thanks gtrig for your help.
When I use the same command you did with the -SHA384 option, I get this in the resulting CSR: "Signature Algorithm: ecdsa-with-SHA384".
Type this command to see the list of supported digests:
openssl list-message-digest-algorithms
Hopefully, you'll see SHA384 in that list.
About your 2nd question, the format is ASN.1. "30" indicates that a sequence follows (In this case, it's a sequence of 2 integers). "65" is the number of octets in the sequence. "02" represents an integer and 30 is the number of octets in that integer. If you skip ahead 0x30 (48 in decimal) octets, you'll come to the 2nd integer which is marked with "02" and "31". So the length of the first integer is 30 and the 2nd is 31. Add in the 2 octets for each integer and you get 65, which is the length of the sequence. This page can tell you more about ASN.1.
As far as this value being a sequence of 2 integers, that makes sense. The ECDSA signature is made up of 2 integers. See RFC6605 section 4 for more information. There is also the wiki page that explains how to calculate the 2 integers.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With