Re: RSA signed ECDSA certificate still uses ECDSA for authentication
On Fri, Aug 26, 2022 at 01:28:21PM -0700, radiatejava wrote: > >> and then the same ECDSA key verified by the CA to sign a hash over the > >> transcript of the handshake itself > > Which part of the TLS handshake you are talking about? Are you talking > about the three messages from the client to server messages that are - > ClientKeyExchange, ChangeCipherSpec, ClientFinished? In my > understanding, ClientKeyExchange, ChangeCipherSpec are not encrypted > and the last one ClientFinished is encrypted but using the keys > derived from ECDHE key exchange algorithm. Is that not right? Other than with TLS 1.0--1.2 anon-DHE and anon-ECDHE ciphersuites, the server key exchange message parameters are signed with the server's public key. If a client certificate is solicited, the client's ClientVerify message is signed with the client's public key. I am not aware of any anon-DHE or anon-ECDHE ciphers for TLS 1.3. I'd advocate for these to be added (for unauthenticated opportunistic TLS), if I did not suspect that there would be little support for them at present. -- Viktor.
Re: RSA signed ECDSA certificate still uses ECDSA for authentication
>> and then the same ECDSA key verified by the CA to sign a hash over the >> transcript of the handshake itself Which part of the TLS handshake you are talking about? Are you talking about the three messages from the client to server messages that are - ClientKeyExchange, ChangeCipherSpec, ClientFinished? In my understanding, ClientKeyExchange, ChangeCipherSpec are not encrypted and the last one ClientFinished is encrypted but using the keys derived from ECDHE key exchange algorithm. Is that not right? On Fri, Aug 26, 2022 at 11:02 AM Nicola Tuveri wrote: > > I'll give it a try. > > The Certification Authority (CA) that released the certificate has an RSA > key. That was used to generate the signature in the cert, that tells users > that the CA verified the Certificate Subject identity and that they hold the > secret key associated with the Subject's Public Key. > > The Certificate Subject (facebook.com) has an ECDSA key, and proved to the CA > that they own the secret key matching the Subject's Public Key indicated in > the certificate. > > During the TLS handshake, facebook.com uses ECDHE for key exchange, and then > the same ECDSA key verified by the CA to sign a hash over the transcript of > the handshake itself, this (plus an extra bit of symmetric authentication not > directly relevant for this discussion) proves to the client that the server > they are talking with holds the ECDSA secret key associated with the > Subject's Public Key of the Certificate: if they trust the CA (or the chain > of trust up to the CA that signed the Certificate) they transitively know > that the server is indeed facebook.com (or someone that gained control of > their secret ECDSA key). > > Therefore ECDHE provides key exchange and ECDSA authentication for the > handshake, while RSA guarantees the authenticity of the Certificate. > > > Best regards, > > Nicola Tuveri > > On Fri, Aug 26, 2022, 20:49 radiatejava wrote: >> >> I am a bit confused when an RSA signed ECDSA certificate is being used in >> TLS. >> For example, if you run the test for facebook.com, you will see that >> the certificate has ECDSA key but signed with Signature Algorithm: >> sha256WithRSAEncryption. >> >> $ openssl s_client -connect www.facebook.com:443 >> >> The ciphersuite used here is ECDHE-ECDSA-AES128-GCM-SHA256. So it >> means it used ECDSA key for server authentication. >> >> But I do not understand how did it use ECDSA key for authentication as >> the cert is RSA signed and key exchange is ECDHE, meaning ECDSA key of >> the certificate is not used for encryption keys. Can someone explain >> this to me?
Re: RSA signed ECDSA certificate still uses ECDSA for authentication
I'll give it a try. The Certification Authority (CA) that released the certificate has an RSA key. That was used to generate the signature in the cert, that tells users that the CA verified the Certificate Subject identity and that they hold the secret key associated with the Subject's Public Key. The Certificate Subject (facebook.com) has an ECDSA key, and proved to the CA that they own the secret key matching the Subject's Public Key indicated in the certificate. During the TLS handshake, facebook.com uses ECDHE for key exchange, and then the same ECDSA key verified by the CA to sign a hash over the transcript of the handshake itself, this (plus an extra bit of symmetric authentication not directly relevant for this discussion) proves to the client that the server they are talking with holds the ECDSA secret key associated with the Subject's Public Key of the Certificate: if they trust the CA (or the chain of trust up to the CA that signed the Certificate) they transitively know that the server is indeed facebook.com (or someone that gained control of their secret ECDSA key). Therefore ECDHE provides key exchange and ECDSA authentication for the handshake, while RSA guarantees the authenticity of the Certificate. Best regards, Nicola Tuveri On Fri, Aug 26, 2022, 20:49 radiatejava wrote: > I am a bit confused when an RSA signed ECDSA certificate is being used in > TLS. > For example, if you run the test for facebook.com, you will see that > the certificate has ECDSA key but signed with Signature Algorithm: > sha256WithRSAEncryption. > > $ openssl s_client -connect www.facebook.com:443 > > The ciphersuite used here is ECDHE-ECDSA-AES128-GCM-SHA256. So it > means it used ECDSA key for server authentication. > > But I do not understand how did it use ECDSA key for authentication as > the cert is RSA signed and key exchange is ECDHE, meaning ECDSA key of > the certificate is not used for encryption keys. Can someone explain > this to me? >
RSA signed ECDSA certificate still uses ECDSA for authentication
I am a bit confused when an RSA signed ECDSA certificate is being used in TLS. For example, if you run the test for facebook.com, you will see that the certificate has ECDSA key but signed with Signature Algorithm: sha256WithRSAEncryption. $ openssl s_client -connect www.facebook.com:443 The ciphersuite used here is ECDHE-ECDSA-AES128-GCM-SHA256. So it means it used ECDSA key for server authentication. But I do not understand how did it use ECDSA key for authentication as the cert is RSA signed and key exchange is ECDHE, meaning ECDSA key of the certificate is not used for encryption keys. Can someone explain this to me?
RE: ECDSA certificate question
Thanks Michael, I tried to invoke SM3 algorithm in command "openssl req -new -key eckey.pem -x509 -sm3 -nodes -days 365 -out cert.csr", unfortunately got the following error: 140320586413888:error:100C508A:elliptic curve routines:pkey_ec_ctrl:invalid digest type:crypto/ec/ec_pmeth.c:331: -Original Message- From: Michael Richardson Sent: Tuesday, September 22, 2020 4:36 PM To: Yan, Bob Cc: openssl-users@openssl.org Subject: Re: ECDSA certificate question Yan, Bob via openssl-users wrote: > Is there a way to generate a ECDSA certificate with SM2 typed public > key and ecdsa-with-SM3 as the signature algorithm in openssl 1.1.1x > version? I don't know the detail with the SM3, part, but have you seen: https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki-09 https://github.com/rgmhtt/draft-moskowitz-ecdsa-pki but, 1.1.1 release notes say it supports SM3. I expect you need to tweak something when "openssl req" is run. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
ECDSA certificate question
Hello everybody, Is there a way to generate a ECDSA certificate with SM2 typed public key and ecdsa-with-SM3 as the signature algorithm in openssl 1.1.1x version? Thank you very much! Bob
Re: [openssl-users] ECDSA Certificate does not work
On 2016-04-28, Viktor Dukhovni wrote: > On Thu, Apr 28, 2016 at 07:44:53AM +0200, Danny wrote: > >> I've been trying to get an ECDSA certificate to work with a Postfix >> installation lately. > > See also http://www.postfix.org/postfix-tls.1.html, which does all > the magic to create RSA and/or ECDSA keys for Postfix 3.1 or later. Thanks for your replies Viktor. I was having the same problem and your solution worked for me also. Oliver -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] ECDSA Certificate does not work
AH! Thanks man. My postfix server seems to work now with ciphers-sets using ECDSA! I just wish openssl would have complained about it (or had given me a warning or something). Anyway, I'm using Postfix 2.11, but either way, I like it when I can do things manually. :P Thanks. On 4/28/16, Viktor Dukhovni <openssl-us...@dukhovni.org> wrote: > On Thu, Apr 28, 2016 at 07:44:53AM +0200, Danny wrote: > >> I've been trying to get an ECDSA certificate to work with a Postfix >> installation lately. > > See also http://www.postfix.org/postfix-tls.1.html, which does all > the magic to create RSA and/or ECDSA keys for Postfix 3.1 or later. > > # postfix tls new-server-cert -a ecdsa -b secp521r1 > > -- > Viktor. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] ECDSA Certificate does not work
On Thu, Apr 28, 2016 at 07:44:53AM +0200, Danny wrote: > I've been trying to get an ECDSA certificate to work with a Postfix > installation lately. See also http://www.postfix.org/postfix-tls.1.html, which does all the magic to create RSA and/or ECDSA keys for Postfix 3.1 or later. # postfix tls new-server-cert -a ecdsa -b secp521r1 -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] ECDSA Certificate does not work
On Thu, Apr 28, 2016 at 07:44:53AM +0200, Danny wrote: > Dear OpenSSL users, > > I've been trying to get an ECDSA certificate to work with a postfix > installation lately. > , however, it seems that when I try to use the aECDSA protocol with a > client the server gives "no shared cipher" errors. > > I had created the certificate like the following: > > openssl ecparam -name secp521r1 -genkey -param_enc explicit -out > private/ec-email-server.pem TLS does not support explicit EC parameters. You must use a named curve by OID. The "-param_enc explicit" option must not be used. You must also enable ECDHE in s_server to use ECDSA, since neither RSA key transport nor DHE are possible. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] ECDSA Certificate does not work
Dear OpenSSL users, I've been trying to get an ECDSA certificate to work with a postfix installation lately. , however, it seems that when I try to use the aECDSA protocol with a client the server gives "no shared cipher" errors. I had created the certificate like the following: openssl ecparam -name secp521r1 -genkey -param_enc explicit -out private/ec-email-server.pem openssl req -new -x509 -key private/ec-email-server.pem -out certs/ec-email-server.pem -days 365 Now, when I test the certificate with s_server and s_client like: openssl s_server -accept 123 -cert /etc/ssl/certs/ec-email-server.pem -key /etc/ssl/private/ec-email-server.pem openssl s_client -connect localhost:123 I still get "no shared cipher" errors. I'm guessing openssl restricts the ciphers to those ciphers that use ECDSA as authentication. However, maybe openssl doesn't allow me (for some reason) to use ECDSA. I'm using Debian and my openssl version is: OpenSSL 1.0.1k 8 Jan 2015 Does anyone know where the issue lies? Thank you -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] ECDHE-ECDSA certificate returning with no shared cipher error
From: openssl-users On Behalf Of Rajeswari K Sent: Monday, February 02, 2015 22:17 Thanks for responding. Following is the output printed by openssl ./openssl req -in csr.csr -noout -text snip Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: ASN1 OID: prime256v1 Yes, that is named form. Then I don't know what the problem is. Generic debugging advice, if you haven't tried these already: Does the problem occur with s_client to your server? Does the problem occur with s_client to s_server using the same certkey, cipherlist (if not default) and same or reasonable tmp-ECDH? Actually, that's a thought. You said your server uses tmp-ECDH callback; does that (always) provide a curve/parameters object that *has* an OID which maps to one of the TLS standard curves in 4492 (and one specified in the client hello but your earlier trace looked like the client specified all). s_server *only* supports named curves (and defaults to p256). ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] ECDHE-ECDSA certificate returning with no shared cipher error
From: openssl-users On Behalf Of Rajeswari K Sent: Sunday, February 01, 2015 21:18 Am facing an issue of no shared cipher error during SSL Handshake, when tried to negotiate ECDHE cipher suite. snip *Feb 2 01:00:47.894: SSL_accept:error in SSLv3 read client hello C *Feb 2 01:00:47.894: 3854049196:error:1408A0C1:SSL routines: SSL3_GET_CLIENT_HELLO:no shared cipher s3_srvr.c:1381: Have updated with temporary ECDH callback during SSL Server initialization. ECDSA certificate is being signed using openssl commands. How was the keypair and CSR generated? In particular, check the publickey in the CSR, and thus in the cert, has the curve encoded in named form (as an OID) not explicit form (with all the details of prime or polynomial, equation coefficients, base point, and cofactor). ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] ECDHE-ECDSA certificate returning with no shared cipher error
Hello Dave, Thanks for responding. Following is the output printed by openssl ./openssl req -in csr.csr -noout -text Certificate Request: Data: Version: 0 (0x0) Subject: CN=eccert/unstructuredName= Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: ASN1 OID: prime256v1 Attributes: Requested Extensions: X509v3 Key Usage: critical Digital Signature Signature Algorithm: ecdsa-with-SHA256 Please share is there any issue with these parameters? Thanks, Rajeswari. On Tue, Feb 3, 2015 at 8:28 AM, Dave Thompson dthomp...@prinpay.com wrote: From: openssl-users On Behalf Of Rajeswari K Sent: Sunday, February 01, 2015 21:18 Am facing an issue of no shared cipher error during SSL Handshake, when tried to negotiate ECDHE cipher suite. snip *Feb 2 01:00:47.894: SSL_accept:error in SSLv3 read client hello C *Feb 2 01:00:47.894: 3854049196:error:1408A0C1:SSL routines: SSL3_GET_CLIENT_HELLO:no shared cipher s3_srvr.c:1381: Have updated with temporary ECDH callback during SSL Server initialization. ECDSA certificate is being signed using openssl commands. How was the keypair and CSR generated? In particular, check the publickey in the CSR, and thus in the cert, has the curve encoded in named form (as an OID) not explicit form (with all the details of prime or polynomial, equation coefficients, base point, and cofactor). ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] ECDHE-ECDSA certificate returning with no shared cipher error
Hello Openssl users, Am facing an issue of no shared cipher error during SSL Handshake, when tried to negotiate ECDHE cipher suite. We are using openssl-1.0.1j version. Can you please share your thoughts? Following are the logs during SSL Handshake. Server has 2 from 0xE29690E0: 0x10B42900:ECDHE-ECDSA-AES256-SHA 0x10B428D0:ECDHE-ECDSA-AES128-SHA Client sent 2 from 0xE442F5B0: 0x10B42900:ECDHE-ECDSA-AES256-SHA 0x10B428D0:ECDHE-ECDSA-AES128-SHA rt=0 rte=0 dht=1 ecdht=1 re=1 ree=1 rs=0 ds=0 dhr=0 dhd=0 0:[0080:0040:0089:0005]0x10B42900:ECDHE-ECDSA-AES256-SHA rt=0 rte=0 dht=1 ecdht=1 re=1 ree=1 rs=0 ds=0 dhr=0 dhd=0 0:[0080:0040:0089:0005]0x10B428D0:ECDHE-ECDSA-AES128-SHA *Feb 2 01:00:46.884: SSL_accept:before/accept initialization *Feb 2 01:00:46.884: SSL_accept:would block on read in SSLv3 read client hello B *Feb 2 01:00:47.892: TLS 1.2 Handshake [length 0092], ClientHello *Feb 2 01:00:47.892: 01 00 00 8E 03 03 C3 CB 15 58 20 B9 49 1D 73 C7 *Feb 2 01:00:47.892: F8 C1 4D 31 10 A1 B6 D9 62 9E DF 91 A8 DC 8F 79 *Feb 2 01:00:47.892: 95 79 20 55 AC CF 00 00 06 C0 0A C0 09 00 FF 01 *Feb 2 01:00:47.893: 00 00 5F 00 0B 00 04 03 00 01 02 00 0A 00 34 00 *Feb 2 01:00:47.893: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 *Feb 2 01:00:47.893: 0A 00 16 00 17 00 08 00 06 00 07 00 14 00 15 00 *Feb 2 01:00:47.893: 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0F 00 *Feb 2 01:00:47.893: 10 00 11 00 0D 00 16 00 14 06 01 06 03 05 01 05 *Feb 2 01:00:47.893: 03 04 01 04 03 03 01 03 03 02 01 02 03 00 0F 00 *Feb 2 01:00:47.893: 01 01 *Feb 2 01:00:47.893: TLS client extension EC point formats (id=11), len=4 *Feb 2 01:00:47.893: 03 00 01 02 *Feb 2 01:00:47.893: TLS client extension elliptic curves (id=10), len=52 *Feb 2 01:00:47.893: 00 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 *Feb 2 01:00:47.893: 00 0A 00 16 00 17 00 08 00 06 00 07 00 14 00 15 *Feb 2 01:00:47.893: 00 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0F *Feb 2 01:00:47.893: 00 10 00 11 *Feb 2 01:00:47.893: TLS client extension signature algorithms (id=13), len=22 *Feb 2 01:00:47.893: 00 14 06 01 06 03 05 01 05 03 04 01 04 03 03 01 *Feb 2 01:00:47.893: 03 03 02 01 02 03 *Feb 2 01:00:47.893: TLS client extension heartbeat (id=15), len=1 *Feb 2 01:00:47.893: 01 *Feb 2 01:00:47.894: TLS 1.2 Alert [length 0002], fatal handshake_failure *Feb 2 01:00:47.894: 02 28 *Feb 2 01:00:47.894: Router# *Feb 2 01:00:47.894: SSL3 alert write:fatal:handshake failure *Feb 2 01:00:47.894: SSL_accept:error in SSLv3 read client hello C *Feb 2 01:00:47.894: 3854049196:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher s3_srvr.c:1381: Have updated with temporary ECDH callback during SSL Server initialization. ECDSA certificate is being signed using openssl commands. Am not seeing any issue with RSA baesd ciphers. But only with ECDSA based ciphers having problem on my setup. Can you please share will the certificate loading is something different than RSA? Thanks, Rajeswari. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
RE: [SPAM?] Re: ECDSA Certificate
and how do I generate an ECDSA certificate? To generate a selfsigned ECDSA cert the same ways you do RSA, except use EC instead of RSA. - use req -new with EC key or -newkey with EC parms and -x509 to generate selfsigned cert directly. - use req -new with key or -newkey to generate CSR, then x509 -req -signkey to create selfsigned cert Set other attributes as appropriate. If you set KeyUsage, it must include digSign to use this cert for ECDHE-ECDSA. (KU for RSA should include digSign or encrypt depending on the suites to be used, but sometimes isn't enforced.) Use a curve supported by the peers you will communicate with. To obtain a CA-signed ECDSA cert the same ways as RSA, except EC instead of RSA, and harder. - generate CSR for EC key as above, for suitable curve - find a CA that issues EC certs, with usage allowing at least digSign=ECDSA. I haven't found any yet. - submit CSR to CA, prove your identity, pay fees. - receive cert and any chain cert(s) from CA. snip __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
ECDSA Certificate
On 08.08.2014 02:11, Dr. Stephen Henson wrote: Well maybe, maybe not. Just because a ciphersuite is included in the cipherlist doesn't mean it is included or could be selected. For example if you set a ciphersuite which uses ECDSA authentication it wont be selected if the server doesn't include an ECDSA certificate. can you please give an example of an ECDSA certificate, Thanks I'm asking this, because one Web-Server connects with |SSL_CIPHER=ECDHE-RSA-AES256-GCM-SHA384 and one with ||SSL_CIPHER=DHE-RSA-AES256-GCM-SHA384| both with the same client; and both Web-Server (Apache) have this SSLCipherSuite RC4-SHA:RC4-MD5:HIGH:MEDIUM:!ADH:!DSS:!SSLv2:+3DES -- Greetings, Walter smime.p7s Description: S/MIME Cryptographic Signature
RE: ECDSA Certificate
Both of those are using an RSA certificate; DHE or ECDHE is key-exchange only not authentication. However the servers must configure *parameters* for temp DH and temp ECDH respectively; do they? For ECDHE the parameters must use one of the (named) curves specified by the client; openssl client supports all named curves, but other clients like browsers might not. Is the second server on not-very-recent RedHat or CentOS? Until late 2013, RedHat openssl packages disabled all elliptic curve crypto due to what they called legal concerns. Everyone believes this meant the Certicom patents, although I don't think they ever confirmed it. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Walter H. Sent: Sunday, August 10, 2014 02:39 To: openssl-users@openssl.org Cc: Dr. Stephen Henson Subject: ECDSA Certificate On 08.08.2014 02:11, Dr. Stephen Henson wrote: Well maybe, maybe not. Just because a ciphersuite is included in the cipherlist doesn't mean it is included or could be selected. For example if you set a ciphersuite which uses ECDSA authentication it wont be selected if the server doesn't include an ECDSA certificate. can you please give an example of an ECDSA certificate, Thanks I'm asking this, because one Web-Server connects with SSL_CIPHER=ECDHE-RSA-AES256-GCM-SHA384 and one with SSL_CIPHER=DHE-RSA-AES256-GCM-SHA384 both with the same client; and both Web-Server (Apache) have this SSLCipherSuite RC4-SHA:RC4-MD5:HIGH:MEDIUM:!ADH:!DSS:!SSLv2:+3DES -- Greetings, Walter
Re: ECDSA Certificate
and how do I generate an ECDSA certificate? On 10.08.2014 14:12, Dave Thompson wrote: Both of those are using an RSA certificate; DHE or ECDHE is key-exchange only not authentication. However the servers must configure **parameters** for temp DH and temp ECDH respectively; do they? I haven't configured none of those ... Is the second server on not-very-recent RedHat or CentOS? Yes, it is a CentOS 6.5 *From:*owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] *On Behalf Of *Walter H. *Sent:* Sunday, August 10, 2014 02:39 *To:* openssl-users@openssl.org *Cc:* Dr. Stephen Henson *Subject:* ECDSA Certificate On 08.08.2014 02:11, Dr. Stephen Henson wrote: Well maybe, maybe not. Just because a ciphersuite is included in the cipherlist doesn't mean it is included or could be selected. For example if you set a ciphersuite which uses ECDSA authentication it wont be selected if the server doesn't include an ECDSA certificate. can you please give an example of an ECDSA certificate, Thanks I'm asking this, because one Web-Server connects with SSL_CIPHER=ECDHE-RSA-AES256-GCM-SHA384 |and one with| |SSL_CIPHER=DHE-RSA-AES256-GCM-SHA384| both with the same client; and both Web-Server (Apache) have this SSLCipherSuite RC4-SHA:RC4-MD5:HIGH:MEDIUM:!ADH:!DSS:!SSLv2:+3DES -- Greetings, Walter -- Mit freundlichen Grüßen, Best regards, Mes salutations distinguées, Ing. Walter Höhlhubmer _/ _/ _/_/ _/ _/ _/_/ Lederergasse 47a/7 _/ _/ _/_/ A-4020 Linz a. d. Donau _/ _/ _/ _/_/_/_/ Austria / EUROPE _/_/_/_/_/ _/_/ _/_/ _/_/ _/_/ [+43 664 951 83 72]_/ _/ _/_/ smime.p7s Description: S/MIME Cryptographic Signature
Server ECDSA certificate requirements for 1.0.1f?
I've got a server that can't negotiate a cipher suite with a client when using ECDSA certificates. When using ECDSA, the server reports 0x1408a0c1 (no shared cipher). The same server can consume RSA and DSA certificates. (In fact, all the public key and certificate routines are generic and only differ by EVP key type, so the same routines produced the RSA, DSA and ECDSA keys and certs). The ECDSA CA and Server certs are built using P-256 (specifically, NID_X9_62_prime256v1) and SHA-256. The server cert verifies as expected: $ openssl verify -CAfile signing-ecdsa-cert.pem server-ecdsa-cert.pem server-ecdsa-cert.pem: OK Server cert signature algorithm is ecdsa-with-SHA256. The cert key usage is Digital Signature, Key Encipherment, Key Agreement. AKI and SKI are present. EKU is *not* present. (Again, these same certs work with RSA and DSA). When loading them into the server, SSL_CTX_use_certificate_chain_file, SSL_CTX_use_PrivateKey_file, and SSL_CTX_check_private_key succeed. I also perform manual verification on the key, the certifcate, and the chain (in addition to OpenSSL's SSL_CTX_check_private_key). Cipher numbers one and two in the server are ECDHE-ECDSA-AES256-GCM-SHA384 and ECDHE-ECDSA-AES128-GCM-SHA256 when using ECDSA. Using default ciphers by removing the call to SSL_CTX_set_cipher_list does not help. When testing under RSA, the ECDH callback is successfully inovked. When teting under ECDSA, the ECDH callback is never invoked. When the negotiation fails, the server's SSL object reports 0x1408a0c1 (no shared cipher). Below is what it looks like from the client's perspective. I found one bug report form 2010 or so mentioning to ECSA and 0x1408a0c1, but it does not appear to be related (the source code no longer looks as described in the bug report). Any ideas what's going on here? Thanks in advance. ** $ /usr/local/ssl/bin/openssl s_client -tls1_2 -connect localhost:8443 -CAfile ./pki/signing-ecdsa-cert.pem CONNECTED(0003) 140404774033064:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1256:SSL alert number 40 140404774033064:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 0 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher: ... Verify return code: 0 (ok) Adding `-cipher` with ECDHE-ECDSA-AES128-GCM-SHA256 and ECDHE-ECDSA-AES256-GCM-SHA384 produce the same results. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 04, 2014 at 06:35:13AM -0500, Jeffrey Walton wrote: I've got a server that can't negotiate a cipher suite with a client when using ECDSA certificates. When using ECDSA, the server reports 0x1408a0c1 (no shared cipher). Did you configure an EECDH (aka ECDHE) curve? With OpenSSL 1.0.[01], the more common ECDSA cipher-suites use kEECDH key agreement. When testing under RSA, the ECDH callback is successfully inovked. When testing under ECDSA, the ECDH callback is never invoked. What is in the (non-extended) keyUsage extension of the certificate? IIRC with EC, if the keyUsage extension is present, the certificate needs to be marked usable for keyAgreement. From ssl/ssl_lib.c: ecdh_ok = (x-ex_flags EXFLAG_KUSAGE) ? (x-ex_kusage X509v3_KU_KEY_AGREEMENT) : 1; and right below that: ecdsa_ok = (x-ex_flags EXFLAG_KUSAGE) ? (x-ex_kusage X509v3_KU_DIGITAL_SIGNATURE) : 1; so you need at least both of digitalSignature and keyAgreement: https://www.openssl.org/docs/apps/x509v3_config.html#Key_Usage_ or don't include the extension at all. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 04, 2014, Viktor Dukhovni wrote: On Tue, Mar 04, 2014 at 06:35:13AM -0500, Jeffrey Walton wrote: I've got a server that can't negotiate a cipher suite with a client when using ECDSA certificates. When using ECDSA, the server reports 0x1408a0c1 (no shared cipher). Did you configure an EECDH (aka ECDHE) curve? With OpenSSL 1.0.[01], the more common ECDSA cipher-suites use kEECDH key agreement. When testing under RSA, the ECDH callback is successfully inovked. When testing under ECDSA, the ECDH callback is never invoked. What is in the (non-extended) keyUsage extension of the certificate? IIRC with EC, if the keyUsage extension is present, the certificate needs to be marked usable for keyAgreement. From ssl/ssl_lib.c: ecdh_ok = (x-ex_flags EXFLAG_KUSAGE) ? (x-ex_kusage X509v3_KU_KEY_AGREEMENT) : 1; and right below that: ecdsa_ok = (x-ex_flags EXFLAG_KUSAGE) ? (x-ex_kusage X509v3_KU_DIGITAL_SIGNATURE) : 1; so you need at least both of digitalSignature and keyAgreement: https://www.openssl.org/docs/apps/x509v3_config.html#Key_Usage_ or don't include the extension at all. Well the two should act as a filter for ciphersuites the server will accept. If digital signature is set any ciphersuites which uses the certificate for signing is permissible: which is normally the ephemeral ones. Additionally an EC temporary curve needs to be set as you point out. If key agreement is set the less common ciphersuites which use the server certificate for ECDH are permitted too. If key usage is absent then both can be used. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 9:02 AM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, Mar 04, 2014 at 06:35:13AM -0500, Jeffrey Walton wrote: I've got a server that can't negotiate a cipher suite with a client when using ECDSA certificates. When using ECDSA, the server reports 0x1408a0c1 (no shared cipher). Did you configure an EECDH (aka ECDHE) curve? With OpenSSL 1.0.[01], the more common ECDSA cipher-suites use kEECDH key agreement. Yes. The server's preferred cipher list is: static const char PREFERRED_CIPHERS[] = ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES256-GCM-SHA384: ECDHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-GCM-SHA384: DHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-SHA: DHE-RSA-AES128-SHA: EDH-RSA-DES-CBC3-SHA: DH-RSA-DES-CBC3-SHA; When testing under RSA, the ECDH callback is successfully inovked. When testing under ECDSA, the ECDH callback is never invoked. What is in the (non-extended) keyUsage extension of the certificate? IIRC with EC, if the keyUsage extension is present, the certificate needs to be marked usable for keyAgreement. From ssl/ssl_lib.c: ecdh_ok = (x-ex_flags EXFLAG_KUSAGE) ? (x-ex_kusage X509v3_KU_KEY_AGREEMENT) : 1; and right below that: ecdsa_ok = (x-ex_flags EXFLAG_KUSAGE) ? (x-ex_kusage X509v3_KU_DIGITAL_SIGNATURE) : 1; so you need at least both of digitalSignature and keyAgreement: https://www.openssl.org/docs/apps/x509v3_config.html#Key_Usage_ or don't include the extension at all. The server's Key Usage is Digital Signature, Key Encipherment, Key Agreement. Non of them are critical. Extended Key Usage is not specified. Its not present in the certifcate (as opposed to present but empty). Let me try adding a EKU of serverAuth to see if that helps. Jeff According to RFC 5280: 4.2.1.12. Extended Key Usage This extension indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension... ... If the extension is present, then the certificate MUST only be used for one of the purposes indicated. I avoided EKU because I've seen some Java clients reject a server's cert due to differences between KU and EKU. Since EKU only offers serverAuth, it can cause problems in key transport schemes. But the really odd thing is RSA and DSA are OK. Its odd that ECDSA is the only cert type causing my head aches. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 10:03 AM, Jeffrey Walton noloa...@gmail.com wrote: On Tue, Mar 4, 2014 at 9:02 AM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, Mar 04, 2014 at 06:35:13AM -0500, Jeffrey Walton wrote: ... What is in the (non-extended) keyUsage extension of the certificate? IIRC with EC, if the keyUsage extension is present, the certificate needs to be marked usable for keyAgreement. From ssl/ssl_lib.c: ecdh_ok = (x-ex_flags EXFLAG_KUSAGE) ? (x-ex_kusage X509v3_KU_KEY_AGREEMENT) : 1; and right below that: ecdsa_ok = (x-ex_flags EXFLAG_KUSAGE) ? (x-ex_kusage X509v3_KU_DIGITAL_SIGNATURE) : 1; so you need at least both of digitalSignature and keyAgreement: https://www.openssl.org/docs/apps/x509v3_config.html#Key_Usage_ or don't include the extension at all. The server's Key Usage is Digital Signature, Key Encipherment, Key Agreement. Non of them are critical. Extended Key Usage is not specified. Its not present in the certifcate (as opposed to present but empty). Let me try adding a EKU of serverAuth to see if that helps. The certifcate now includes EKU of TLS Web Server Authentication. But still no joy. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 04, 2014 at 10:03:54AM -0500, Jeffrey Walton wrote: What is in the (non-extended) keyUsage extension of the certificate? IIRC with EC, if the keyUsage extension is present, the certificate needs to be marked usable for keyAgreement. From ssl/ssl_lib.c: ecdh_ok = (x-ex_flags EXFLAG_KUSAGE) ? (x-ex_kusage X509v3_KU_KEY_AGREEMENT) : 1; and right below that: ecdsa_ok = (x-ex_flags EXFLAG_KUSAGE) ? (x-ex_kusage X509v3_KU_DIGITAL_SIGNATURE) : 1; so you need at least both of digitalSignature and keyAgreement: https://www.openssl.org/docs/apps/x509v3_config.html#Key_Usage_ or don't include the extension at all. The server's Key Usage is Digital Signature, Key Encipherment, Key Agreement. None of them are critical. That should be sufficient. The next couple of lines in ssl_lib.c are: if (!(cpk-valid_flags CERT_PKEY_SIGN)) ecdsa_ok = 0; I am not familiar with the circumstances under which this might be false. Let me try adding a EKU of serverAuth to see if that helps. Does the TLS client actually offer any ECDSA ciphers? It needs to negotiate TLSv1 or higher to send a TLS extensions with a list of supported curves. You should check the content of the client SSL HELLO with wireshark or similar. Does the certificate/private key combination in question work with openssl s_server as the server? -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 04, 2014, Jeffrey Walton wrote: On Tue, Mar 4, 2014 at 9:02 AM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, Mar 04, 2014 at 06:35:13AM -0500, Jeffrey Walton wrote: I've got a server that can't negotiate a cipher suite with a client when using ECDSA certificates. When using ECDSA, the server reports 0x1408a0c1 (no shared cipher). Did you configure an EECDH (aka ECDHE) curve? With OpenSSL 1.0.[01], the more common ECDSA cipher-suites use kEECDH key agreement. Yes. The server's preferred cipher list is: static const char PREFERRED_CIPHERS[] = ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES256-GCM-SHA384: ECDHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-GCM-SHA384: DHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-SHA: DHE-RSA-AES128-SHA: EDH-RSA-DES-CBC3-SHA: DH-RSA-DES-CBC3-SHA; Silly question time . Viktor asked if you'd set an ECDHE curve and you responded saying yes and a list of ciphersuites which by themselves don't set a curve. So just to double check: you did set a temporary curve parameters using something like SSL_CTX_set_tmp_ecdh? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 11:19 AM, Dr. Stephen Henson st...@openssl.org wrote:
On Tue, Mar 04, 2014, Jeffrey Walton wrote:
On Tue, Mar 4, 2014 at 9:02 AM, Viktor Dukhovni
openssl-us...@dukhovni.org wrote:
On Tue, Mar 04, 2014 at 06:35:13AM -0500, Jeffrey Walton wrote:
I've got a server that can't negotiate a cipher suite with a client
when using ECDSA certificates. When using ECDSA, the server reports
0x1408a0c1 (no shared cipher).
Did you configure an EECDH (aka ECDHE) curve? With OpenSSL 1.0.[01],
the more common ECDSA cipher-suites use kEECDH key agreement.
Yes. The server's preferred cipher list is:
static const char PREFERRED_CIPHERS[] =
ECDHE-ECDSA-AES256-GCM-SHA384:
ECDHE-ECDSA-AES128-GCM-SHA256:
ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-RSA-AES128-GCM-SHA256:
DHE-RSA-AES256-GCM-SHA384:
DHE-RSA-AES128-GCM-SHA256:
DHE-RSA-AES256-SHA:
DHE-RSA-AES128-SHA:
EDH-RSA-DES-CBC3-SHA:
DH-RSA-DES-CBC3-SHA;
Silly question time . Viktor asked if you'd set an ECDHE curve and you
responded saying yes and a list of ciphersuites which by themselves don't
set a curve.
So just to double check: you did set a temporary curve parameters using
something like SSL_CTX_set_tmp_ecdh?
This is in the server's context setup code:
SSL_CTX_set_tmp_dh_callback(ctx, DH_callback);
SSL_CTX_set_tmp_ecdh_callback(ctx, ECDH_callback);
And:
EC_KEY* ECDH_callback(SSL *ssl, int is_export, int keylength)
{
return ECDH256();
}
Finally:
static EC_KEY* ECDH256()
{
EC_KEY* key = EC_KEY_new_by_curve_name(NistCurveToNidByBits(256));
unsigned long err = ERR_get_error();
...
return key;
}
NistCurveToNidByBits(256) returns NID_X9_62_prime256v1. I also tried
returning NID_secp256k1 with the same result.
I'm setting up Wireshark now on another machine to get the trace.
Jeff
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 04, 2014, Jeffrey Walton wrote:
On Tue, Mar 4, 2014 at 11:19 AM, Dr. Stephen Henson st...@openssl.org wrote:
On Tue, Mar 04, 2014, Jeffrey Walton wrote:
On Tue, Mar 4, 2014 at 9:02 AM, Viktor Dukhovni
openssl-us...@dukhovni.org wrote:
On Tue, Mar 04, 2014 at 06:35:13AM -0500, Jeffrey Walton wrote:
I've got a server that can't negotiate a cipher suite with a client
when using ECDSA certificates. When using ECDSA, the server reports
0x1408a0c1 (no shared cipher).
Did you configure an EECDH (aka ECDHE) curve? With OpenSSL 1.0.[01],
the more common ECDSA cipher-suites use kEECDH key agreement.
Yes. The server's preferred cipher list is:
static const char PREFERRED_CIPHERS[] =
ECDHE-ECDSA-AES256-GCM-SHA384:
ECDHE-ECDSA-AES128-GCM-SHA256:
ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-RSA-AES128-GCM-SHA256:
DHE-RSA-AES256-GCM-SHA384:
DHE-RSA-AES128-GCM-SHA256:
DHE-RSA-AES256-SHA:
DHE-RSA-AES128-SHA:
EDH-RSA-DES-CBC3-SHA:
DH-RSA-DES-CBC3-SHA;
Silly question time . Viktor asked if you'd set an ECDHE curve and you
responded saying yes and a list of ciphersuites which by themselves don't
set a curve.
So just to double check: you did set a temporary curve parameters using
something like SSL_CTX_set_tmp_ecdh?
This is in the server's context setup code:
SSL_CTX_set_tmp_dh_callback(ctx, DH_callback);
SSL_CTX_set_tmp_ecdh_callback(ctx, ECDH_callback);
And:
EC_KEY* ECDH_callback(SSL *ssl, int is_export, int keylength)
{
return ECDH256();
}
Finally:
static EC_KEY* ECDH256()
{
EC_KEY* key = EC_KEY_new_by_curve_name(NistCurveToNidByBits(256));
unsigned long err = ERR_get_error();
...
return key;
}
NistCurveToNidByBits(256) returns NID_X9_62_prime256v1. I also tried
returning NID_secp256k1 with the same result.
I'm setting up Wireshark now on another machine to get the trace.
Can you check to see if ECDH_callback is being called at all? I suspect it
isn't.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 04, 2014 at 05:46:45PM +0100, Dr. Stephen Henson wrote: NistCurveToNidByBits(256) returns NID_X9_62_prime256v1. I also tried returning NID_secp256k1 with the same result. I'm setting up Wireshark now on another machine to get the trace. Can you check to see if ECDH_callback is being called at all? I suspect it isn't. Perhaps the server's EC private key is not being set correctly, so it can't use the certificate. Also the callback does not appear to be caching the ECDHE key, possibly leaking a key for every handshake (if it were ever called). -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 11:46 AM, Dr. Stephen Henson st...@openssl.org wrote: On Tue, Mar 04, 2014, Jeffrey Walton wrote: On Tue, Mar 4, 2014 at 11:19 AM, Dr. Stephen Henson st...@openssl.org wrote: On Tue, Mar 04, 2014, Jeffrey Walton wrote: On Tue, Mar 4, 2014 at 9:02 AM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, Mar 04, 2014 at 06:35:13AM -0500, Jeffrey Walton wrote: I've got a server that can't negotiate a cipher suite with a client when using ECDSA certificates. When using ECDSA, the server reports 0x1408a0c1 (no shared cipher). Did you configure an EECDH (aka ECDHE) curve? With OpenSSL 1.0.[01], the more common ECDSA cipher-suites use kEECDH key agreement. Yes. The server's preferred cipher list is: static const char PREFERRED_CIPHERS[] = ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES256-GCM-SHA384: ECDHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-GCM-SHA384: DHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-SHA: DHE-RSA-AES128-SHA: EDH-RSA-DES-CBC3-SHA: DH-RSA-DES-CBC3-SHA; Silly question time . Viktor asked if you'd set an ECDHE curve and you responded saying yes and a list of ciphersuites which by themselves don't set a curve. So just to double check: you did set a temporary curve parameters using something like SSL_CTX_set_tmp_ecdh? This is in the server's context setup code: SSL_CTX_set_tmp_dh_callback(ctx, DH_callback); SSL_CTX_set_tmp_ecdh_callback(ctx, ECDH_callback); And: ... Can you check to see if ECDH_callback is being called at all? I suspect it isn't. There's actually a debug logging line in ECDH_callback. Its not being called when using the ECDSA cert. (And it is being called when RSA cert is used). Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 11:51 AM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, Mar 04, 2014 at 05:46:45PM +0100, Dr. Stephen Henson wrote: NistCurveToNidByBits(256) returns NID_X9_62_prime256v1. I also tried returning NID_secp256k1 with the same result. I'm setting up Wireshark now on another machine to get the trace. Can you check to see if ECDH_callback is being called at all? I suspect it isn't. Perhaps the server's EC private key is not being set correctly, so it can't use the certificate. Is there a way to test this? Also the callback does not appear to be caching the ECDHE key, possibly leaking a key for every handshake (if it were ever called). OK, I have not gotten that far. Thanks for the heads up. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 11:46 AM, Dr. Stephen Henson st...@openssl.org wrote:
On Tue, Mar 04, 2014, Jeffrey Walton wrote:
On Tue, Mar 4, 2014 at 11:19 AM, Dr. Stephen Henson st...@openssl.org
wrote:
On Tue, Mar 04, 2014, Jeffrey Walton wrote:
On Tue, Mar 4, 2014 at 9:02 AM, Viktor Dukhovni
openssl-us...@dukhovni.org wrote:
On Tue, Mar 04, 2014 at 06:35:13AM -0500, Jeffrey Walton wrote:
I've got a server that can't negotiate a cipher suite with a client
when using ECDSA certificates. When using ECDSA, the server reports
0x1408a0c1 (no shared cipher).
Did you configure an EECDH (aka ECDHE) curve? With OpenSSL 1.0.[01],
the more common ECDSA cipher-suites use kEECDH key agreement.
Yes. The server's preferred cipher list is:
static const char PREFERRED_CIPHERS[] =
ECDHE-ECDSA-AES256-GCM-SHA384:
ECDHE-ECDSA-AES128-GCM-SHA256:
ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-RSA-AES128-GCM-SHA256:
DHE-RSA-AES256-GCM-SHA384:
DHE-RSA-AES128-GCM-SHA256:
DHE-RSA-AES256-SHA:
DHE-RSA-AES128-SHA:
EDH-RSA-DES-CBC3-SHA:
DH-RSA-DES-CBC3-SHA;
Silly question time . Viktor asked if you'd set an ECDHE curve and you
responded saying yes and a list of ciphersuites which by themselves don't
set a curve.
So just to double check: you did set a temporary curve parameters using
something like SSL_CTX_set_tmp_ecdh?
This is in the server's context setup code:
SSL_CTX_set_tmp_dh_callback(ctx, DH_callback);
SSL_CTX_set_tmp_ecdh_callback(ctx, ECDH_callback);
And:
EC_KEY* ECDH_callback(SSL *ssl, int is_export, int keylength)
{
return ECDH256();
}
Finally:
static EC_KEY* ECDH256()
{
EC_KEY* key = EC_KEY_new_by_curve_name(NistCurveToNidByBits(256));
unsigned long err = ERR_get_error();
...
return key;
}
NistCurveToNidByBits(256) returns NID_X9_62_prime256v1. I also tried
returning NID_secp256k1 with the same result.
I'm setting up Wireshark now on another machine to get the trace.
Can you check to see if ECDH_callback is being called at all? I suspect it
isn't.
Going back to my config notes:
# Open Configure, change '-O3' to '-Os'
# Open Configure, add '-g3' to target linux-x86_64
./config fips shared no-ssl2 no-ec2m enable-ec_nistp_64_gcc_128
no-srp no-psk
openssl-fips-ecp-2.0.5.tar.gz is the underlying fips tar ball.
Do any of the config options set off alarm bells? (I'm getting ready
to try a build using -O3).
Jeff
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 11:41 AM, Jeffrey Walton noloa...@gmail.com wrote: On Tue, Mar 4, 2014 at 11:19 AM, Dr. Stephen Henson st...@openssl.org wrote: ... I'm setting up Wireshark now on another machine to get the trace. The Wireshark trace is useless (to me) because its only displaying TCP traffic (and not breaking out the SSL/TLS protocol). I can't break the bits out in my head. Here's -debug from a separate s_client on a different physical machine. $ /usr/local/ssl/bin/openssl s_client -tls1_2 -connect debian-q500:8443 -cipher ECDHE-ECDSA-AES128-GCM-SHA256 -debug CONNECTED(0003) write to 0x736bc0 [0x7406f3] (163 bytes = 163 (0xA3)) - 16 03 01 00 9e 01 00 00-9a 03 03 12 a5 1d c3 7e ...~ 0010 - 5e e1 dc 20 c3 9e da dd-cb 66 8f 0b d0 6c 24 13 ^.. .f...l$. 0020 - e0 b5 de ef 54 5f cd 2c-4c 53 37 00 00 04 c0 2b T_.,LS7+ 0030 - 00 ff 01 00 00 6d 00 0b-00 04 03 00 01 02 00 0a .m.. 0040 - 00 34 00 32 00 0e 00 0d-00 19 00 0b 00 0c 00 18 .4.2 0050 - 00 09 00 0a 00 16 00 17-00 08 00 06 00 07 00 14 0060 - 00 15 00 04 00 05 00 12-00 13 00 01 00 02 00 03 0070 - 00 0f 00 10 00 11 00 23-00 00 00 0d 00 20 00 1e ...#. .. 0080 - 06 01 06 02 06 03 05 01-05 02 05 03 04 01 04 02 0090 - 04 03 03 01 03 02 03 03-02 01 02 02 02 03 00 0f 00a0 - 00 01 01 ... read from 0x736bc0 [0x73c1a3] (5 bytes = 5 (0x5)) - 15 03 03 00 02. read from 0x736bc0 [0x73c1a8] (2 bytes = 2 (0x2)) - 02 28 .( 139925962778272:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1256:SSL alert number 40 139925962778272:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 0 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher: Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None SRP username: None Start Time: 1393954054 Timeout : 7200 (sec) Verify return code: 0 (ok) --- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 04, 2014, Jeffrey Walton wrote: On Tue, Mar 4, 2014 at 11:41 AM, Jeffrey Walton noloa...@gmail.com wrote: On Tue, Mar 4, 2014 at 11:19 AM, Dr. Stephen Henson st...@openssl.org wrote: ... I'm setting up Wireshark now on another machine to get the trace. The Wireshark trace is useless (to me) because its only displaying TCP traffic (and not breaking out the SSL/TLS protocol). I can't break the bits out in my head. Here's -debug from a separate s_client on a different physical machine. If you use OpenSSL 1.0.2 and you configure with enable-ssl-trace you get a -trace option added to s_client/s_server which is *very* useful for debugging. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 04, 2014 at 11:59:42AM -0500, Jeffrey Walton wrote: Perhaps the server's EC private key is not being set correctly, so it can't use the certificate. Is there a way to test this? Usually, after setting a key and a certificate chain, one calls SSL_CTX_check_private_key(ctx) to check that the most recent cert and key loaded are compatible. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 04, 2014 at 12:34:22PM -0500, Jeffrey Walton wrote: I'm setting up Wireshark now on another machine to get the trace. The Wireshark trace is useless (to me) because its only displaying TCP traffic (and not breaking out the SSL/TLS protocol). I can't break the bits out in my head. The wireshark gui decodes SSL handshakes everywhere I've tried it, but you have to have the right compile-time options, and ask it to decode as ssl. Here's -debug from a separate s_client on a different physical machine. $ /usr/local/ssl/bin/openssl s_client -tls1_2 -connect debian-q500:8443 -cipher ECDHE-ECDSA-AES128-GCM-SHA256 -debug CONNECTED(0003) write to 0x736bc0 [0x7406f3] (163 bytes = 163 (0xA3)) - 16 03 01 00 9e 01 00 00-9a 03 03 12 a5 1d c3 7e ...~ 0010 - 5e e1 dc 20 c3 9e da dd-cb 66 8f 0b d0 6c 24 13 ^.. .f...l$. 0020 - e0 b5 de ef 54 5f cd 2c-4c 53 37 00 00 04 c0 2b T_.,LS7+ 0030 - 00 ff 01 00 00 6d 00 0b-00 04 03 00 01 02 00 0a .m.. 0040 - 00 34 00 32 00 0e 00 0d-00 19 00 0b 00 0c 00 18 .4.2 0050 - 00 09 00 0a 00 16 00 17-00 08 00 06 00 07 00 14 0060 - 00 15 00 04 00 05 00 12-00 13 00 01 00 02 00 03 0070 - 00 0f 00 10 00 11 00 23-00 00 00 0d 00 20 00 1e ...#. .. 0080 - 06 01 06 02 06 03 05 01-05 02 05 03 04 01 04 02 0090 - 04 03 03 01 03 02 03 03-02 01 02 02 02 03 00 0f 00a0 - 00 01 01 ... Find a decoder, or post a PCAP file. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 1:28 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, Mar 04, 2014 at 11:59:42AM -0500, Jeffrey Walton wrote: Perhaps the server's EC private key is not being set correctly, so it can't use the certificate. Is there a way to test this? Usually, after setting a key and a certificate chain, one calls SSL_CTX_check_private_key(ctx) to check that the most recent cert and key loaded are compatible. Yes, did that. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 12:34 PM, Jeffrey Walton noloa...@gmail.com wrote: On Tue, Mar 4, 2014 at 11:41 AM, Jeffrey Walton noloa...@gmail.com wrote: On Tue, Mar 4, 2014 at 11:19 AM, Dr. Stephen Henson st...@openssl.org wrote: ... I'm setting up Wireshark now on another machine to get the trace. The Wireshark trace is useless (to me) because its only displaying TCP traffic (and not breaking out the SSL/TLS protocol). I can't break the bits out in my head. Here's -debug from a separate s_client on a different physical machine. $ /usr/local/ssl/bin/openssl s_client -tls1_2 -connect debian-q500:8443 -cipher ECDHE-ECDSA-AES128-GCM-SHA256 -debug Here's the dump from s_server. $ /usr/local/ssl/bin/openssl s_server -accept 8443 -cert server-ecdsa-cert.pem -key server-ecdsa-key-plain.pem -debug Using default temp DH parameters Using default temp ECDH parameters ACCEPT read from 0x13f0550 [0x13f5c40] (11 bytes = 11 (0xB)) - 16 03 01 01 2e 01 00 01-2a 03 03 *.. read from 0x13f0550 [0x13f5c4e] (296 bytes = 296 (0x128)) - 07 de ce 27 aa ae 3e bf-e2 31 73 46 0d 4a 50 cc ...'1sF.JP. 0010 - f2 09 0f 3e a0 1d 59 d8-e7 63 93 ea 39 37 f4 92 .Y..c..97.. 0020 - 00 00 94 c0 30 c0 2c c0-28 c0 24 c0 14 c0 0a 00 0.,.(.$. 0030 - a3 00 9f 00 6b 00 6a 00-39 00 38 00 88 00 87 c0 k.j.9.8. 0040 - 32 c0 2e c0 2a c0 26 c0-0f c0 05 00 9d 00 3d 00 2...*=. 0050 - 35 00 84 c0 12 c0 08 00-16 00 13 c0 0d c0 03 00 5... 0060 - 0a c0 2f c0 2b c0 27 c0-23 c0 13 c0 09 00 a2 00 ../.+.'.#... 0070 - 9e 00 67 00 40 00 33 00-32 00 9a 00 99 00 45 00 ..g.@.3.2.E. 0080 - 44 c0 31 c0 2d c0 29 c0-25 c0 0e c0 04 00 9c 00 D.1.-.).%... 0090 - 3c 00 2f 00 96 00 41 00-07 c0 11 c0 07 c0 0c c0 ./...A. 00a0 - 02 00 05 00 04 00 15 00-12 00 09 00 14 00 11 00 00b0 - 08 00 06 00 03 00 ff 01-00 00 6d 00 0b 00 04 03 ..m. 00c0 - 00 01 02 00 0a 00 34 00-32 00 0e 00 0d 00 19 00 ..4.2... 00d0 - 0b 00 0c 00 18 00 09 00-0a 00 16 00 17 00 08 00 00e0 - 06 00 07 00 14 00 15 00-04 00 05 00 12 00 13 00 00f0 - 01 00 02 00 03 00 0f 00-10 00 11 00 23 00 00 00 #... 0100 - 0d 00 20 00 1e 06 01 06-02 06 03 05 01 05 02 05 .. . 0110 - 03 04 01 04 02 04 03 03-01 03 02 03 03 02 01 02 0120 - 02 02 03 00 0f 00 01 01- write to 0x13f0550 [0x13ff730] (7 bytes = 7 (0x7)) - 15 03 03 00 02 02 28 ..( ERROR 140339533272744:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1353: shutting down SSL CONNECTION CLOSED __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 1:33 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, Mar 04, 2014 at 12:34:22PM -0500, Jeffrey Walton wrote: I'm setting up Wireshark now on another machine to get the trace. The Wireshark trace is useless (to me) because its only displaying TCP traffic (and not breaking out the SSL/TLS protocol). I can't break the bits out in my head. The wireshark gui decodes SSL handshakes everywhere I've tried it, but you have to have the right compile-time options, and ask it to decode as ssl. Here's what I got on two different machines: http://postimg.org/image/wxxfx0exd/. Perhaps I have missed a Wireshark configuration option somewhere (most of the time, its port 443 so everything works as expected). Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
From: owner-openssl-us...@openssl.org On Behalf Of Jeffrey Walton Sent: Tuesday, March 04, 2014 12:34 The Wireshark trace is useless (to me) because its only displaying TCP traffic (and not breaking out the SSL/TLS protocol). I can't break the bits out in my head. right-click one of your packets in the packet list, DecodeAs..., make sure Transport has your port number (here 8443), pick SSL in the list at the right, OK. Here's -debug from a separate s_client on a different physical machine. $ /usr/local/ssl/bin/openssl s_client -tls1_2 -connect debian-q500:8443 -cipher ECDHE-ECDSA-AES128-GCM-SHA256 -debug CONNECTED(0003) write to 0x736bc0 [0x7406f3] (163 bytes = 163 (0xA3)) - 16 03 01 00 9e 01 00 00-9a 03 03 12 a5 1d c3 7e ...~ 0010 - 5e e1 dc 20 c3 9e da dd-cb 66 8f 0b d0 6c 24 13 ^.. .f...l$. 0020 - e0 b5 de ef 54 5f cd 2c-4c 53 37 00 00 04 c0 2b T_.,LS7+ 0030 - 00 ff 01 00 00 6d 00 0b-00 04 03 00 01 02 00 0a .m.. 0040 - 00 34 00 32 00 0e 00 0d-00 19 00 0b 00 0c 00 18 .4.2 0050 - 00 09 00 0a 00 16 00 17-00 08 00 06 00 07 00 14 0060 - 00 15 00 04 00 05 00 12-00 13 00 01 00 02 00 03 0070 - 00 0f 00 10 00 11 00 23-00 00 00 0d 00 20 00 1e ...#. .. bytes at 42 through 75 are (body of) supported_curves and does include 00 17 which is P-256 -- which s_client always does. 0080 - 06 01 06 02 06 03 05 01-05 02 05 03 04 01 04 02 0090 - 04 03 03 01 03 02 03 03-02 01 02 02 02 03 00 0f 00a0 - 00 01 01 ... read from 0x736bc0 [0x73c1a3] (5 bytes = 5 (0x5)) - 15 03 03 00 02. read from 0x736bc0 [0x73c1a8] (2 bytes = 2 (0x2)) - 02 28 .( 139925962778272:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1256:SSL alert number 40 139925962778272:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596: snip but that reminds me: does your ECDSA cert have the publickey in named=OID format, NOT explicit (prime + coefficients + point + order etc.)? If your real client, like openssl, only offers named curves not explicit, a cert containing an explicit key cannot be selected, even if the explicit parameters are actually the parameters for a name-able curve. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 6:35 AM, Jeffrey Walton noloa...@gmail.com wrote: I've got a server that can't negotiate a cipher suite with a client when using ECDSA certificates. When using ECDSA, the server reports 0x1408a0c1 (no shared cipher). The same server can consume RSA and DSA certificates. (In fact, all the public key and certificate routines are generic and only differ by EVP key type, so the same routines produced the RSA, DSA and ECDSA keys and certs). The ECDSA CA and Server certs are built using P-256 (specifically, NID_X9_62_prime256v1) and SHA-256. Here's a test set of keys and certs: http://wiki.openssl.org/index.php/file:ecdsa-keys-and-certs.tar.gz. The files are PEM-encoded and described below:: * signing-ecdsa-cert.pem - the CA cert * signing-ecdsa-key-plain.pem - the CA key, no password * server-ecdsa-cert.pem - the server cert * server-ecdsa-key-plain.pem - the server key, no password The server has two SANs and one is 'localhost', so it should be testable. Sorry to put it on the OpenSSL wiki. I'm not up on file sharing sites, and I don't know where to go to avoid porn and malware. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 2:00 PM, Dave Thompson dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of Jeffrey Walton Sent: Tuesday, March 04, 2014 12:34 ... but that reminds me: does your ECDSA cert have the publickey in named=OID format, NOT explicit (prime + coefficients + point + order etc.)? If your real client, like openssl, only offers named curves not explicit, a cert containing an explicit key cannot be selected, even if the explicit parameters are actually the parameters for a name-able curve. If that's the case, then that's probably it. Below is a sample. I've been using PEM_write_PKCS8PrivateKey and PEM_write_X509. What does one use to write the named curve? Thanks for the help. $ openssl x509 -in server-ecdsa-cert.pem -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 2718864780398442230 (0x25bb591cd3f836f6) Signature Algorithm: ecdsa-with-SHA256 Issuer: C=US, O=Example, LLC, CN=Example, LLC Certification Authority Validity Not Before: Mar 3 00:00:00 2014 GMT Not After : Mar 12 00:00:00 2014 GMT Subject: O=Example, LLC/emailAddress=supp...@example.com, CN=Example, LLC Proxy Certificate Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:0e:2d:72:28:74:9f:0c:88:e4:25:a3:d4:09:1e: e6:7a:d0:97:89:ed:a4:8d:97:a7:56:aa:63:9d:ee: 94:a1:dd:2d:67:91:8a:88:1f:f9:ba:c3:22:1d:11: c6:8a:7e:a6:72:57:37:cf:dd:fc:eb:01:ca:5a:32: 55:5e:99:da:1c 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 Alternative Name: DNS:debian-q500 X509v3 Subject Alternative Name: DNS:localhost X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Key Encipherment, Key Agreement Netscape Comment: Powered by OpenSSL X509v3 Subject Key Identifier: 6A:12:D9:BD:F1:C1:33:A8:68:C9:9C:F6:51:99:3F:49:1E:5C:BF:DA X509v3 Authority Key Identifier: keyid:BD:84:4D:C6:A7:22:72:E9:91:08:4E:FA:50:5C:12:73:22:3A:02:7E Signature Algorithm: ecdsa-with-SHA256 30:44:02:20:7d:0d:5b:9f:7a:68:c5:a7:4f:37:f1:2b:43:5b: c7:77:bb:c6:6d:cd:2d:cf:78:dc:bd:13:2e:f8:16:72:9e:bc: 02:20:68:d5:71:45:48:b6:01:23:0a:87:e1:96:ff:8d:1d:c9: 5d:d0:62:ce:5d:ba:ce:c2:fa:73:29:d4:0d:c8:f1:1c __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 04, 2014, Jeffrey Walton wrote: If that's the case, then that's probably it. Below is a sample. I've been using PEM_write_PKCS8PrivateKey and PEM_write_X509. What does one use to write the named curve? It is stored in the private key when the key is generated. How did you generate it? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 2:25 PM, Dr. Stephen Henson st...@openssl.org wrote: On Tue, Mar 04, 2014, Jeffrey Walton wrote: If that's the case, then that's probably it. Below is a sample. I've been using PEM_write_PKCS8PrivateKey and PEM_write_X509. What does one use to write the named curve? It is stored in the private key when the key is generated. How did you generate it? int nid = ... EC_KEY* key = EC_KEY_new_by_curve_name(nid); int rc = EC_KEY_generate_key(key); EVP_PKEY * pkey = EVP_PKEY_new(); rc = EVP_PKEY_assign_EC_KEY(pkey, key); Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 04, 2014, Jeffrey Walton wrote: On Tue, Mar 4, 2014 at 2:25 PM, Dr. Stephen Henson st...@openssl.org wrote: On Tue, Mar 04, 2014, Jeffrey Walton wrote: If that's the case, then that's probably it. Below is a sample. I've been using PEM_write_PKCS8PrivateKey and PEM_write_X509. What does one use to write the named curve? It is stored in the private key when the key is generated. How did you generate it? int nid = ... EC_KEY* key = EC_KEY_new_by_curve_name(nid); int rc = EC_KEY_generate_key(key); EVP_PKEY * pkey = EVP_PKEY_new(); rc = EVP_PKEY_assign_EC_KEY(pkey, key); Ah, the default is unfortunately to use explicit parameters. You can change that with: EC_KEY_set_asn1_flag(key, OPENSSL_EC_NAMED_CURVE); Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Server ECDSA certificate requirements for 1.0.1f?
From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Jeffrey Walton Sent: Tuesday, 04 March, 2014 13:43 On Tue, Mar 4, 2014 at 1:33 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: The wireshark gui decodes SSL handshakes everywhere I've tried it, but you have to have the right compile-time options, and ask it to decode as ssl. Here's what I got on two different machines: http://postimg.org/image/wxxfx0exd/. Perhaps I have missed a Wireshark configuration option somewhere (most of the time, its port 443 so everything works as expected). Open the Analyze menu (or right-click on a packet in the upper frame), select Decode as..., and pick SSL from the list. Note that Wireshark is only able to decode encrypted traffic under fairly stringent conditions: it needs an RSA-keyed cipher suite, it has to be built with the appropriate support, it has to be built to use GnuTLS rather than OpenSSL or BSAFE as its SSL/TLS library, and it has to have access to the server's private key. But even without all that it can decode the unencrypted portions of the flows. The Wireshark documentation is decent. See http://wiki.wireshark.org/SSL to start; the wireshark.org search function finds a lot more information about SSL/TLS dissection. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 3:26 PM, Dr. Stephen Henson st...@openssl.org wrote: On Tue, Mar 04, 2014, Jeffrey Walton wrote: On Tue, Mar 4, 2014 at 2:25 PM, Dr. Stephen Henson st...@openssl.org wrote: ... It is stored in the private key when the key is generated. How did you generate it? int nid = ... EC_KEY* key = EC_KEY_new_by_curve_name(nid); int rc = EC_KEY_generate_key(key); EVP_PKEY * pkey = EVP_PKEY_new(); rc = EVP_PKEY_assign_EC_KEY(pkey, key); Ah, the default is unfortunately to use explicit parameters. You can change that with: EC_KEY_set_asn1_flag(key, OPENSSL_EC_NAMED_CURVE); That was it. Thank you guys very much. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 3:26 PM, Dr. Stephen Henson st...@openssl.org wrote: On Tue, Mar 04, 2014, Jeffrey Walton wrote: On Tue, Mar 4, 2014 at 2:25 PM, Dr. Stephen Henson st...@openssl.org wrote: ... int nid = ... EC_KEY* key = EC_KEY_new_by_curve_name(nid); int rc = EC_KEY_generate_key(key); EVP_PKEY * pkey = EVP_PKEY_new(); rc = EVP_PKEY_assign_EC_KEY(pkey, key); Ah, the default is unfortunately to use explicit parameters. You can change that with: EC_KEY_set_asn1_flag(key, OPENSSL_EC_NAMED_CURVE); Would you happen to know if its a problem with the key, the certificate, or both? I ask because I have my own validation routines, and I can add additional checks so the issue can be spotted early in code and logged to the appropriate place. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Problem with verifying of PKCS7-structure signed with ECDSA-certificate
Hello! I try to check signature on PKCS7-structure(see attached file pkcs7.bin). The following sequence of commands is performed: openssl pkcs7 -in pkcs7.bin -inform DER -outform PEM -out pkcs7.PEM openssl smime -verify -in pkcs7.PEM -inform pem -noverify 1pkcs7.data Verification failure 3980:error:2107C080:PKCS7 routines:PKCS7_get0_signers:signer certificate not found:.\crypto\pkcs7\pk7_smime.c:378: OpenSSL says that it cannot find signer certificate. But output of command openssl asn1parse -inform DER -in pkcs7.bin shows that certificate is present. What's wrong? Sincerelly, Alexei Soloview. pkcs7.bin Description: Binary data
Re: Problem with verifying of PKCS7-structure signed with ECDSA-certificate
On Fri, Feb 26, 2010, Alexei Soloview wrote: Hello! I try to check signature on PKCS7-structure(see attached file pkcs7.bin). The following sequence of commands is performed: openssl pkcs7 -in pkcs7.bin -inform DER -outform PEM -out pkcs7.PEM openssl smime -verify -in pkcs7.PEM -inform pem -noverify 1pkcs7.data Verification failure 3980:error:2107C080:PKCS7 routines:PKCS7_get0_signers:signer certificate not found:.\crypto\pkcs7\pk7_smime.c:378: OpenSSL says that it cannot find signer certificate. But output of command openssl asn1parse -inform DER -in pkcs7.bin shows that certificate is present. What's wrong? The PKCS#7 structure is broken. In OpenSSL 1.0 you can see this clearly with the command: openssl -cmsout -in pkcs7.bin -inform DER -noout -print The signerInfo structure points to the signer's certificate: signerInfos: version: 1 d.issuerAndSerialNumber: issuer: CN=CSCA, O=assa abloy itg, C=de serialNumber: 1 While the certificate itself has: issuer: C=de, O=assa abloy itg, CN=CSCA The ordering is reversed: order is significant in DNs so the two do not match. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Client for a server with self-signed ECDSA certificate
Hi ,I was looking for a client which can support my https server which uses ECDSA. I have looked into http://dev.experimentalstuff.com:8082/mozilla/index.html but the link to download the binaries are down. If anyone can provide me a browser with that cipher suite supported so that a handshake with the server can be possible and hence i can test my application.Btw how i test this server with s_client feature of open-ssl . I think we have to provide some option for a self signed certificate. A example of the same will be nice. -- Regards,Puneet BaturaOpen Source Developer
How to generate ECDSA certificate in OPenssl
Hi, I want to try generate ECDSA certificate and set up ECDH in key agreement, using Openssl. 1. Which version of OPenssl should I install? 2. Where can I get the document or examples? Hung-Yu Chien
Re: Re: How to generate ECDSA certificate in OPenssl
Hi Nils, Appreciate your kind help. I just want to generate the ECC certificate in command line, use it for a web server. I also want to set up the environment to test ECDH key agreement. Thanks in advance. Hung-Yu -- Original Message --- From: Nils Larsch [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thu, 16 Dec 2004 11:32:26 +0100 Subject: Re: How to generate ECDSA certificate in OPenssl [EMAIL PROTECTED] wrote: Hi, I want to try generate ECDSA certificate and set up ECDH in key agreement, using Openssl. command line or c code ? note: to be honest I'm not sure in how far the current openssl ecc tls implementation is complying with the latest ecc tls draft. 1. Which version of OPenssl should I install? the cvs head 2. Where can I get the document or examples? this depends on the first question Cheers, Nils __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] --- End of Original Message ---
Re: How to generate ECDSA certificate in OPenssl
[EMAIL PROTECTED] wrote: Hi, I want to try generate ECDSA certificate and set up ECDH in key agreement, using Openssl. command line or c code ? note: to be honest I'm not sure in how far the current openssl ecc tls implementation is complying with the latest ecc tls draft. 1. Which version of OPenssl should I install? the cvs head 2. Where can I get the document or examples? this depends on the first question Cheers, Nils __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: How to generate ECDSA certificate in OPenssl
[EMAIL PROTECTED] wrote: Hi Nils, Appreciate your kind help. I just want to generate the ECC certificate in command line, use it for a web server. use apps/ecparam.c to create a private ec key or just ec parameters (see ecparam manpage [1]) and then use this key/params in openssl req -newkey ec:params.pem ... etc. (once you have a private key the type of that key shouldn't really matter anymore, as this is mostly hidden from the normal user). I also want to set up the environment to test ECDH key agreement. Thanks in advance. using openssl s_server ... you can do this by choosing an appropriate ec cipher via the -cipher option (for a list of supported ec ciphers see ssl/tls1.h). Cheers, Nils [1] there are some typos in the manpage: in the examples section ec should be replaced by ecparam will fix it. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
