Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
ECDSA testing with s_client/s_server
588 views
Skip to first unread message
Erik Tkal
Aug 1, 2012, 4:33:24 PM8/1/12
to
I'm playing around to see if I can observe client and server under various conditions when negotiating TLS 1.2 with newer certs. I created a root and server cert as ecdsa-with-SHA256.
openssl s_server -CAfile eroot1.pem -cert eserver1.pem -key eserver1.key -debug
openssl s_client -CAfile eroot1.pem -debug
However, the server issues a handshake alert and says no shared cipher. I see the client is sending a large set of suites but apparently none that the server wants. How do I do this properly?
ACCEPT
read from 0x147cb28 [0x1489e60] (11 bytes => 11 (0xB))
0000 - 16 03 01 01 3c 01 00 01-38 03 03 ....<...8..
read from 0x147cb28 [0x1489e6e] (310 bytes => 310 (0x136))
0000 - 50 19 91 ea 00 45 14 d9-c4 bc 4d 15 a1 e5 0a a3 P....E....M.....
0010 - f4 89 1d a5 98 37 2d 28-14 a2 19 47 b4 92 e8 dd .....7-(...G....
0020 - 00 00 a0 c0 30 c0 2c c0-28 c0 24 c0 14 c0 0a c0 ....0.,.(.$.....
0030 - 22 c0 21 00 a3 00 9f 00-6b 00 6a 00 39 00 38 00 ".!.....k.j.9.8.
0040 - 88 00 87 c0 32 c0 2e c0-2a c0 26 c0 0f c0 05 00 ....2...*.&.....
0050 - 9d 00 3d 00 35 00 84 c0-12 c0 08 c0 1c c0 1b 00 ..=.5...........
0060 - 16 00 13 c0 0d c0 03 00-0a c0 2f c0 2b c0 27 c0 ........../.+.'.
0070 - 23 c0 13 c0 09 c0 1f c0-1e 00 a2 00 9e 00 67 00 #.............g.
0080 - 40 00 33 00 32 00 9a 00-99 00 45 00 44 c0 31 c0 @.3.2.....E.D.1.
0090 - 2d c0 29 c0 25 c0 0e c0-04 00 9c 00 3c 00 2f 00 -.).%.......<./.
00a0 - 96 00 41 00 07 c0 11 c0-07 c0 0c c0 02 00 05 00 ..A.............
00b0 - 04 00 15 00 12 00 09 00-14 00 11 00 08 00 06 00 ................
00c0 - 03 00 ff 01 00 00 6f 00-0b 00 04 03 00 01 02 00 ......o.........
00d0 - 0a 00 34 00 32 00 0e 00-0d 00 19 00 0b 00 0c 00 ..4.2...........
00e0 - 18 00 09 00 0a 00 16 00-17 00 08 00 06 00 07 00 ................
00f0 - 14 00 15 00 04 00 05 00-12 00 13 00 01 00 02 00 ................
0100 - 03 00 0f 00 10 00 11 00-23 00 00 00 0d 00 22 00 ........#.....".
0110 - 20 06 01 06 02 06 03 05-01 05 02 05 03 04 01 04 ...............
0120 - 02 04 03 03 01 03 02 03-03 02 01 02 02 02 03 01 ................
0130 - 01 00 0f 00 01 01 ......
write to 0x147cb28 [0x1493870] (7 bytes => 7 (0x7))
0000 - 15 03 03 00 02 02 28 ......(
ERROR
5368:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:.\ssl\s3_srvr.c:1353:
shutting down SSL
CONNECTION CLOSED
....................................
Erik Tkal
Juniper OAC/UAC/Pulse Development
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
openssl s_server -CAfile eroot1.pem -cert eserver1.pem -key eserver1.key -debug
openssl s_client -CAfile eroot1.pem -debug
However, the server issues a handshake alert and says no shared cipher. I see the client is sending a large set of suites but apparently none that the server wants. How do I do this properly?
ACCEPT
read from 0x147cb28 [0x1489e60] (11 bytes => 11 (0xB))
0000 - 16 03 01 01 3c 01 00 01-38 03 03 ....<...8..
read from 0x147cb28 [0x1489e6e] (310 bytes => 310 (0x136))
0000 - 50 19 91 ea 00 45 14 d9-c4 bc 4d 15 a1 e5 0a a3 P....E....M.....
0010 - f4 89 1d a5 98 37 2d 28-14 a2 19 47 b4 92 e8 dd .....7-(...G....
0020 - 00 00 a0 c0 30 c0 2c c0-28 c0 24 c0 14 c0 0a c0 ....0.,.(.$.....
0030 - 22 c0 21 00 a3 00 9f 00-6b 00 6a 00 39 00 38 00 ".!.....k.j.9.8.
0040 - 88 00 87 c0 32 c0 2e c0-2a c0 26 c0 0f c0 05 00 ....2...*.&.....
0050 - 9d 00 3d 00 35 00 84 c0-12 c0 08 c0 1c c0 1b 00 ..=.5...........
0060 - 16 00 13 c0 0d c0 03 00-0a c0 2f c0 2b c0 27 c0 ........../.+.'.
0070 - 23 c0 13 c0 09 c0 1f c0-1e 00 a2 00 9e 00 67 00 #.............g.
0080 - 40 00 33 00 32 00 9a 00-99 00 45 00 44 c0 31 c0 @.3.2.....E.D.1.
0090 - 2d c0 29 c0 25 c0 0e c0-04 00 9c 00 3c 00 2f 00 -.).%.......<./.
00a0 - 96 00 41 00 07 c0 11 c0-07 c0 0c c0 02 00 05 00 ..A.............
00b0 - 04 00 15 00 12 00 09 00-14 00 11 00 08 00 06 00 ................
00c0 - 03 00 ff 01 00 00 6f 00-0b 00 04 03 00 01 02 00 ......o.........
00d0 - 0a 00 34 00 32 00 0e 00-0d 00 19 00 0b 00 0c 00 ..4.2...........
00e0 - 18 00 09 00 0a 00 16 00-17 00 08 00 06 00 07 00 ................
00f0 - 14 00 15 00 04 00 05 00-12 00 13 00 01 00 02 00 ................
0100 - 03 00 0f 00 10 00 11 00-23 00 00 00 0d 00 22 00 ........#.....".
0110 - 20 06 01 06 02 06 03 05-01 05 02 05 03 04 01 04 ...............
0120 - 02 04 03 03 01 03 02 03-03 02 01 02 02 02 03 01 ................
0130 - 01 00 0f 00 01 01 ......
write to 0x147cb28 [0x1493870] (7 bytes => 7 (0x7))
0000 - 15 03 03 00 02 02 28 ......(
ERROR
5368:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:.\ssl\s3_srvr.c:1353:
shutting down SSL
CONNECTION CLOSED
....................................
Erik Tkal
Juniper OAC/UAC/Pulse Development
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Dave Thompson
Aug 2, 2012, 9:55:50 PM8/2/12
to
> From: owner-ope...@openssl.org On Behalf Of Erik Tkal
> Sent: Wednesday, 01 August, 2012 16:33
> I'm playing around to see if I can observe client and server
> under various conditions when negotiating TLS 1.2 with newer
> certs. I created a root and server cert as ecdsa-with-SHA256.
>
> openssl s_server -CAfile eroot1.pem -cert eserver1.pem -key
> eserver1.key -debug
>
> openssl s_client -CAfile eroot1.pem -debug
>
Aside: s_server doesn't need CAfile if you don't do client-auth.
> However, the server issues a handshake alert and says no
> shared cipher. I see the client is sending a large set of
> suites but apparently none that the server wants. How do I
> do this properly?
<snip>
Only thing I can see that would fail silently is if your key
doesn't use a named curve. In general OpenSSL server will skip
ECC suites if the (certified) key is in a format not offered by
the client in SupportedFormats, but s_client (at least) offers
all defined formats; or using a curve not offered by the client
in SupportedCurves, and s_client offers all named curves but not
ad-hoc ones. Also it will skip EECDH suites if your temp ECDH
key uses a curve not offered by the client, but s_server always
does temp named curves (NIST/X962 P256 by default).
> Sent: Wednesday, 01 August, 2012 16:33
> I'm playing around to see if I can observe client and server
> under various conditions when negotiating TLS 1.2 with newer
> certs. I created a root and server cert as ecdsa-with-SHA256.
>
> openssl s_server -CAfile eroot1.pem -cert eserver1.pem -key
> eserver1.key -debug
>
> openssl s_client -CAfile eroot1.pem -debug
>
> However, the server issues a handshake alert and says no
> shared cipher. I see the client is sending a large set of
> suites but apparently none that the server wants. How do I
> do this properly?
Only thing I can see that would fail silently is if your key
doesn't use a named curve. In general OpenSSL server will skip
ECC suites if the (certified) key is in a format not offered by
the client in SupportedFormats, but s_client (at least) offers
all defined formats; or using a curve not offered by the client
in SupportedCurves, and s_client offers all named curves but not
ad-hoc ones. Also it will skip EECDH suites if your temp ECDH
key uses a curve not offered by the client, but s_server always
does temp named curves (NIST/X962 P256 by default).
Erik Tkal
Aug 3, 2012, 3:30:59 PM8/3/12
to
I debugged this to see what is happening, and it seems that the server is looking at the configured certificate and key and deciding that the client needs to be sending 0xFF01 (it is finding NID_X9_62_prime_field as the field type). However, the client is sending the full list of standard named curves.
I create the key using NID_X9_62_prime256v1 as follows (abbreviated):
EVP_PKEY* key = NULL;
EC_KEY* eck = NULL;
BIGNUM* e = NULL;
EC_GROUP* ecgroup = NULL;
eck = EC_KEY_new();
if ( !eck )
goto err;
ecgroup = EC_GROUP_new_by_curve_name(NID_X9_62_prime256v1);
if ( !ecgroup )
goto err;
if ( !EC_KEY_set_group(eck, ecgroup) )
goto err;
if( !EC_KEY_generate_key( eck ) )
goto err;
if( !EVP_PKEY_assign_EC_KEY( key, eck ) )
goto err;
EC_GROUP_free(ecgroup);
Is there something I am doing incorrectly to generate the EC key?
....................................
Erik Tkal
Juniper OAC/UAC/Pulse Development
I create the key using NID_X9_62_prime256v1 as follows (abbreviated):
EVP_PKEY* key = NULL;
EC_KEY* eck = NULL;
BIGNUM* e = NULL;
EC_GROUP* ecgroup = NULL;
eck = EC_KEY_new();
if ( !eck )
goto err;
ecgroup = EC_GROUP_new_by_curve_name(NID_X9_62_prime256v1);
if ( !ecgroup )
goto err;
if ( !EC_KEY_set_group(eck, ecgroup) )
goto err;
if( !EC_KEY_generate_key( eck ) )
goto err;
if( !EVP_PKEY_assign_EC_KEY( key, eck ) )
goto err;
EC_GROUP_free(ecgroup);
Is there something I am doing incorrectly to generate the EC key?
....................................
Erik Tkal
Juniper OAC/UAC/Pulse Development
-----Original Message-----
From: owner-ope...@openssl.org [mailto:owner-ope...@openssl.org] On Behalf Of Erik Tkal
Sent: Wednesday, August 01, 2012 4:33 PM
To: openss...@openssl.org
Subject: ECDSA testing with s_client/s_server
I'm playing around to see if I can observe client and server under various conditions when negotiating TLS 1.2 with newer certs. I created a root and server cert as ecdsa-with-SHA256.
openssl s_server -CAfile eroot1.pem -cert eserver1.pem -key eserver1.key -debug
openssl s_client -CAfile eroot1.pem -debug
From: owner-ope...@openssl.org [mailto:owner-ope...@openssl.org] On Behalf Of Erik Tkal
Sent: Wednesday, August 01, 2012 4:33 PM
To: openss...@openssl.org
Subject: ECDSA testing with s_client/s_server
I'm playing around to see if I can observe client and server under various conditions when negotiating TLS 1.2 with newer certs. I created a root and server cert as ecdsa-with-SHA256.
openssl s_server -CAfile eroot1.pem -cert eserver1.pem -key eserver1.key -debug
openssl s_client -CAfile eroot1.pem -debug
However, the server issues a handshake alert and says no shared cipher. I see the client is sending a large set of suites but apparently none that the server wants. How do I do this properly?
Dr. Stephen Henson
Aug 3, 2012, 5:56:38 PM8/3/12
to
On Fri, Aug 03, 2012, Erik Tkal wrote:
> I debugged this to see what is happening, and it seems that the server is looking at the configured certificate and key and deciding that the client needs to be sending 0xFF01 (it is finding NID_X9_62_prime_field as the field type). However, the client is sending the full list of standard named curves.
>
> I create the key using NID_X9_62_prime256v1 as follows (abbreviated):
>
What does the server certificate look like? Does it have a keyUsage extension
> I debugged this to see what is happening, and it seems that the server is looking at the configured certificate and key and deciding that the client needs to be sending 0xFF01 (it is finding NID_X9_62_prime_field as the field type). However, the client is sending the full list of standard named curves.
>
> I create the key using NID_X9_62_prime256v1 as follows (abbreviated):
>
and if so what is it set to?
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
Erik Tkal
Aug 3, 2012, 6:37:34 PM8/3/12
to
Hi Steve, here's the cert:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 34474 (0x86aa)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=eRoot1, OU=Engineering, O=Juniper Networks, Inc., L=Westford, ST=MA, C=US
Validity
Not Before: Aug 1 19:04:20 2012 GMT
Not After : Jul 30 19:04:20 2022 GMT
Subject: CN=eServer1, OU=Engineering, O=Juniper Networks, Inc., L=Westford, ST=MA, C=US
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:e9:7e:4c:b3:44:eb:21:a4:15:9d:9a:2e:5e:e3:
3c:09:19:22:36:cf:01:ee:dc:b8:67:1b:78:30:e0:
dd:4c:7f:95:38:24:f1:0c:7d:1c:2b:ab:b8:67:b7:
ef:42:9c:b6:df:fd:49:fb:1a:85:57:c1:e4:5a:e4:
b6:7c:4b:40:3b
Field Type: prime-field
Prime:
00:ff:ff:ff:ff:00:00:00:01:00:00:00:00:00:00:
00:00:00:00:00:00:ff:ff:ff:ff:ff:ff:ff:ff:ff:
ff:ff:ff
A:
00:ff:ff:ff:ff:00:00:00:01:00:00:00:00:00:00:
00:00:00:00:00:00:ff:ff:ff:ff:ff:ff:ff:ff:ff:
ff:ff:fc
B:
5a:c6:35:d8:aa:3a:93:e7:b3:eb:bd:55:76:98:86:
bc:65:1d:06:b0:cc:53:b0:f6:3b:ce:3c:3e:27:d2:
60:4b
Generator (uncompressed):
04:6b:17:d1:f2:e1:2c:42:47:f8:bc:e6:e5:63:a4:
40:f2:77:03:7d:81:2d:eb:33:a0:f4:a1:39:45:d8:
98:c2:96:4f:e3:42:e2:fe:1a:7f:9b:8e:e7:eb:4a:
7c:0f:9e:16:2b:ce:33:57:6b:31:5e:ce:cb:b6:40:
68:37:bf:51:f5
Order:
00:ff:ff:ff:ff:00:00:00:00:ff:ff:ff:ff:ff:ff:
ff:ff:bc:e6:fa:ad:a7:17:9e:84:f3:b9:ca:c2:fc:
63:25:51
Cofactor: 1 (0x1)
Seed:
c4:9d:36:08:86:e7:04:93:6a:66:78:e1:13:9d:26:
b7:81:9f:7e:90
X509v3 extensions:
X509v3 Subject Key Identifier:
E5:15:BA:0A:AB:56:A3:4C:47:4E:54:6D:21:93:0E:98:3B:CB:E9:3B
X509v3 Subject Alternative Name:
DNS:eserver1.juniper.net
X509v3 Authority Key Identifier:
keyid:F8:87:1E:2B:4D:8D:F1:96:B9:9A:D8:BA:15:D0:75:FF:F4:1A:A4:9C
DirName:/CN=eRoot1/OU=Engineering/O=Juniper Networks, Inc./L=Westford/ST=MA/C=US
serial:D3:27
X509v3 Key Usage:
Digital Signature
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://localhost/pkitool/eroot1/eroot1.crl
Signature Algorithm: ecdsa-with-SHA256
30:45:02:21:00:d2:30:0d:5f:5c:61:45:ef:23:a5:ae:04:3a:
ca:50:d0:a0:54:ca:ce:93:1c:b7:8a:04:19:b3:9f:ed:b4:1b:
f0:02:20:33:7b:55:bd:b8:df:ca:e5:42:db:49:e3:23:8a:f9:
5d:6b:09:d2:b1:13:c8:60:46:0b:99:57:80:4d:ef:19:42
-----BEGIN CERTIFICATE-----
MIIEGjCCA8CgAwIBAgIDAIaqMAoGCCqGSM49BAMCMHUxDzANBgNVBAMTBmVSb290
MTEUMBIGA1UECxMLRW5naW5lZXJpbmcxHzAdBgNVBAoTFkp1bmlwZXIgTmV0d29y
a3MsIEluYy4xETAPBgNVBAcTCFdlc3Rmb3JkMQswCQYDVQQIEwJNQTELMAkGA1UE
BhMCVVMwHhcNMTIwODAxMTkwNDIwWhcNMjIwNzMwMTkwNDIwWjB3MREwDwYDVQQD
EwhlU2VydmVyMTEUMBIGA1UECxMLRW5naW5lZXJpbmcxHzAdBgNVBAoTFkp1bmlw
ZXIgTmV0d29ya3MsIEluYy4xETAPBgNVBAcTCFdlc3Rmb3JkMQswCQYDVQQIEwJN
QTELMAkGA1UEBhMCVVMwggFLMIIBAwYHKoZIzj0CATCB9wIBATAsBgcqhkjOPQEB
AiEA/////wAAAAEAAAAAAAAAAAAAAAD///////////////8wWwQg/////wAAAAEA
AAAAAAAAAAAAAAD///////////////wEIFrGNdiqOpPns+u9VXaYhrxlHQawzFOw
9jvOPD4n0mBLAxUAxJ02CIbnBJNqZnjhE50mt4GffpAEQQRrF9Hy4SxCR/i85uVj
pEDydwN9gS3rM6D0oTlF2JjClk/jQuL+Gn+bjufrSnwPnhYrzjNXazFezsu2QGg3
v1H1AiEA/////wAAAAD//////////7zm+q2nF56E87nKwvxjJVECAQEDQgAE6X5M
s0TrIaQVnZouXuM8CRkiNs8B7ty4Zxt4MODdTH+VOCTxDH0cK6u4Z7fvQpy23/1J
+xqFV8HkWuS2fEtAO6OCAUcwggFDMB0GA1UdDgQWBBTlFboKq1ajTEdOVG0hkw6Y
O8vpOzAfBgNVHREEGDAWghRlc2VydmVyMS5qdW5pcGVyLm5ldDCBoQYDVR0jBIGZ
MIGWgBT4hx4rTY3xlrma2LoV0HX/9BqknKF5pHcwdTEPMA0GA1UEAxMGZVJvb3Qx
MRQwEgYDVQQLEwtFbmdpbmVlcmluZzEfMB0GA1UEChMWSnVuaXBlciBOZXR3b3Jr
cywgSW5jLjERMA8GA1UEBxMIV2VzdGZvcmQxCzAJBgNVBAgTAk1BMQswCQYDVQQG
EwJVU4IDANMnMAsGA1UdDwQEAwIHgDATBgNVHSUEDDAKBggrBgEFBQcDATA7BgNV
HR8ENDAyMDCgLqAshipodHRwOi8vbG9jYWxob3N0L3BraXRvb2wvZXJvb3QxL2Vy
b290MS5jcmwwCgYIKoZIzj0EAwIDSAAwRQIhANIwDV9cYUXvI6WuBDrKUNCgVMrO
kxy3igQZs5/ttBvwAiAze1W9uN/K5ULbSeMjivldawnSsRPIYEYLmVeATe8ZQg==
-----END CERTIFICATE-----
....................................
Erik Tkal
Juniper OAC/UAC/Pulse Development
-----Original Message-----
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 34474 (0x86aa)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=eRoot1, OU=Engineering, O=Juniper Networks, Inc., L=Westford, ST=MA, C=US
Validity
Not Before: Aug 1 19:04:20 2012 GMT
Not After : Jul 30 19:04:20 2022 GMT
Subject: CN=eServer1, OU=Engineering, O=Juniper Networks, Inc., L=Westford, ST=MA, C=US
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:e9:7e:4c:b3:44:eb:21:a4:15:9d:9a:2e:5e:e3:
3c:09:19:22:36:cf:01:ee:dc:b8:67:1b:78:30:e0:
dd:4c:7f:95:38:24:f1:0c:7d:1c:2b:ab:b8:67:b7:
ef:42:9c:b6:df:fd:49:fb:1a:85:57:c1:e4:5a:e4:
b6:7c:4b:40:3b
Field Type: prime-field
Prime:
00:ff:ff:ff:ff:00:00:00:01:00:00:00:00:00:00:
00:00:00:00:00:00:ff:ff:ff:ff:ff:ff:ff:ff:ff:
ff:ff:ff
A:
00:ff:ff:ff:ff:00:00:00:01:00:00:00:00:00:00:
00:00:00:00:00:00:ff:ff:ff:ff:ff:ff:ff:ff:ff:
ff:ff:fc
B:
5a:c6:35:d8:aa:3a:93:e7:b3:eb:bd:55:76:98:86:
bc:65:1d:06:b0:cc:53:b0:f6:3b:ce:3c:3e:27:d2:
60:4b
Generator (uncompressed):
04:6b:17:d1:f2:e1:2c:42:47:f8:bc:e6:e5:63:a4:
40:f2:77:03:7d:81:2d:eb:33:a0:f4:a1:39:45:d8:
98:c2:96:4f:e3:42:e2:fe:1a:7f:9b:8e:e7:eb:4a:
7c:0f:9e:16:2b:ce:33:57:6b:31:5e:ce:cb:b6:40:
68:37:bf:51:f5
Order:
00:ff:ff:ff:ff:00:00:00:00:ff:ff:ff:ff:ff:ff:
ff:ff:bc:e6:fa:ad:a7:17:9e:84:f3:b9:ca:c2:fc:
63:25:51
Cofactor: 1 (0x1)
Seed:
c4:9d:36:08:86:e7:04:93:6a:66:78:e1:13:9d:26:
b7:81:9f:7e:90
X509v3 extensions:
X509v3 Subject Key Identifier:
E5:15:BA:0A:AB:56:A3:4C:47:4E:54:6D:21:93:0E:98:3B:CB:E9:3B
X509v3 Subject Alternative Name:
DNS:eserver1.juniper.net
X509v3 Authority Key Identifier:
keyid:F8:87:1E:2B:4D:8D:F1:96:B9:9A:D8:BA:15:D0:75:FF:F4:1A:A4:9C
DirName:/CN=eRoot1/OU=Engineering/O=Juniper Networks, Inc./L=Westford/ST=MA/C=US
serial:D3:27
X509v3 Key Usage:
Digital Signature
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://localhost/pkitool/eroot1/eroot1.crl
Signature Algorithm: ecdsa-with-SHA256
30:45:02:21:00:d2:30:0d:5f:5c:61:45:ef:23:a5:ae:04:3a:
ca:50:d0:a0:54:ca:ce:93:1c:b7:8a:04:19:b3:9f:ed:b4:1b:
f0:02:20:33:7b:55:bd:b8:df:ca:e5:42:db:49:e3:23:8a:f9:
5d:6b:09:d2:b1:13:c8:60:46:0b:99:57:80:4d:ef:19:42
-----BEGIN CERTIFICATE-----
MIIEGjCCA8CgAwIBAgIDAIaqMAoGCCqGSM49BAMCMHUxDzANBgNVBAMTBmVSb290
MTEUMBIGA1UECxMLRW5naW5lZXJpbmcxHzAdBgNVBAoTFkp1bmlwZXIgTmV0d29y
a3MsIEluYy4xETAPBgNVBAcTCFdlc3Rmb3JkMQswCQYDVQQIEwJNQTELMAkGA1UE
BhMCVVMwHhcNMTIwODAxMTkwNDIwWhcNMjIwNzMwMTkwNDIwWjB3MREwDwYDVQQD
EwhlU2VydmVyMTEUMBIGA1UECxMLRW5naW5lZXJpbmcxHzAdBgNVBAoTFkp1bmlw
ZXIgTmV0d29ya3MsIEluYy4xETAPBgNVBAcTCFdlc3Rmb3JkMQswCQYDVQQIEwJN
QTELMAkGA1UEBhMCVVMwggFLMIIBAwYHKoZIzj0CATCB9wIBATAsBgcqhkjOPQEB
AiEA/////wAAAAEAAAAAAAAAAAAAAAD///////////////8wWwQg/////wAAAAEA
AAAAAAAAAAAAAAD///////////////wEIFrGNdiqOpPns+u9VXaYhrxlHQawzFOw
9jvOPD4n0mBLAxUAxJ02CIbnBJNqZnjhE50mt4GffpAEQQRrF9Hy4SxCR/i85uVj
pEDydwN9gS3rM6D0oTlF2JjClk/jQuL+Gn+bjufrSnwPnhYrzjNXazFezsu2QGg3
v1H1AiEA/////wAAAAD//////////7zm+q2nF56E87nKwvxjJVECAQEDQgAE6X5M
s0TrIaQVnZouXuM8CRkiNs8B7ty4Zxt4MODdTH+VOCTxDH0cK6u4Z7fvQpy23/1J
+xqFV8HkWuS2fEtAO6OCAUcwggFDMB0GA1UdDgQWBBTlFboKq1ajTEdOVG0hkw6Y
O8vpOzAfBgNVHREEGDAWghRlc2VydmVyMS5qdW5pcGVyLm5ldDCBoQYDVR0jBIGZ
MIGWgBT4hx4rTY3xlrma2LoV0HX/9BqknKF5pHcwdTEPMA0GA1UEAxMGZVJvb3Qx
MRQwEgYDVQQLEwtFbmdpbmVlcmluZzEfMB0GA1UEChMWSnVuaXBlciBOZXR3b3Jr
cywgSW5jLjERMA8GA1UEBxMIV2VzdGZvcmQxCzAJBgNVBAgTAk1BMQswCQYDVQQG
EwJVU4IDANMnMAsGA1UdDwQEAwIHgDATBgNVHSUEDDAKBggrBgEFBQcDATA7BgNV
HR8ENDAyMDCgLqAshipodHRwOi8vbG9jYWxob3N0L3BraXRvb2wvZXJvb3QxL2Vy
b290MS5jcmwwCgYIKoZIzj0EAwIDSAAwRQIhANIwDV9cYUXvI6WuBDrKUNCgVMrO
kxy3igQZs5/ttBvwAiAze1W9uN/K5ULbSeMjivldawnSsRPIYEYLmVeATe8ZQg==
-----END CERTIFICATE-----
....................................
Erik Tkal
Juniper OAC/UAC/Pulse Development
-----Original Message-----
Dr. Stephen Henson
Aug 3, 2012, 6:54:46 PM8/3/12
to
curved. When you generate the key try calling:
EC_GROUP_set_asn1_flag(group, OPENSSL_EC_NAMED_CURVE);
Erik Tkal
Aug 6, 2012, 9:20:18 AM8/6/12
to
Hi Steve,
Thanks, that certainly corrected it. I guess I'm perplexed as to why using
ecgroup = EC_GROUP_new_by_curve_name(NID_X9_62_prime256v1);
would not automatically set that flag since I'm explicitly giving the curve name already?
Thanks,
Erik
....................................
Erik Tkal
Juniper OAC/UAC/Pulse Development
Thanks, that certainly corrected it. I guess I'm perplexed as to why using
ecgroup = EC_GROUP_new_by_curve_name(NID_X9_62_prime256v1);
would not automatically set that flag since I'm explicitly giving the curve name already?
Thanks,
Erik
....................................
Erik Tkal
Juniper OAC/UAC/Pulse Development
0 new messages