Re: with Cavium Engine, hitting unable-to-get-issuer-cert-locally
On Fri, Jan 12, 2007, Elwin Stelzer Eliazer wrote: Following is a summary of some more observations related to this, for your refence: Case-1: No engine used, both at s_client and s_server side In this case, the programs are working fine, and the client and server are able to send messages. Case-2: s_client with cavium engine, and s_server default (the case mentioned in the earlier email) In this case, i am getting the following messages. At s_client side: engine cavium set. CONNECTED(0004) depth=0 /C=AU/ST=Queensland/O=CryptSoft Pty Ltd/CN=Server test cert (512 bit) verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /C=AU/ST=Queensland/O=CryptSoft Pty Ltd/CN=Server test cert (512 bit) verify error:num=27:certificate not trusted verify return:1 depth=0 /C=AU/ST=Queensland/O=CryptSoft Pty Ltd/CN=Server test cert (512 bit) verify error:num=21:unable to verify the first certificate verify return:1 12054:error:1408D07B:SSL routines:SSL3_GET_KEY_EXCHANGE:bad signature:s3_clnt.c:1357: At s_server side: Using default temp DH parameters Using default temp ECDH parameters ACCEPT ERROR 12053:error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error:s3_pkt.c:1057:SSL alert number 51 shutting down SSL CONNECTION CLOSED ACCEPT Case-3: s_client default, and s_server using cavium engine In this case, i am getting the following messages. At s_client side: CONNECTED(0003) 12056:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188: At s_server side: engine cavium set. Using default temp DH parameters Using default temp ECDH parameters ACCEPT ERROR 12055:error:1409B004:SSL routines:SSL3_SEND_SERVER_KEY_EXCHANGE:RSA lib:s3_srvr.c:1477: shutting down SSL CONNECTION CLOSED ACCEPT That indicates that the RSA operations and not producing the correct results when redirected to the ENGINE. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Problems with ciphers (handshake failure)
Hello, I have test it excuting openssl s_client -connect 172.22.2.45:20998 -tls1 -debug and the answer is: Loading 'screen' into random state - done CONNECTED(0770) write to 0xa4e8f0 [0xa586a8] (88 bytes = 88 (0x58)) - 16 03 01 00 53 01 00 00-4f 03 01 45 a7 80 e0 90 S...O..E 0010 - 74 0e fd f6 38 a6 c8 ae-96 8d 0a 67 9e e4 e0 c9 t...8..g 0020 - 4d eb 9a 3a 17 d5 d2 cb-14 a4 4f 00 00 28 00 39 M..:..O..(.9 0030 - 00 38 00 35 00 16 00 13-00 0a 00 33 00 32 00 2f .8.5...3.2./ 0040 - 00 07 00 05 00 04 00 15-00 12 00 09 00 14 00 11 0050 - 00 08 00 06 00 03 01 ... 0058 - SPACES/NULS After decoding this packet: 16 - handshake protocol type 03 01 - TLS1 proposition 00 53 - size of rest data 01 - client_hello packet 00 00-4f size of rest data 03 01 - TLS1 version 45 a7 80 e0 90 ... cb-14 a4 4f - client random (32 bytes) 00 - session id length 00 28 - cipher suite length 00 39 - DHE_RSA_WITH_AES_256_SHA 00 38 - DHE_DSS_WITH_AES_256_SHA 00 35 - RSA_WITH_AES_256_SHA 00 16 - EDH_RSA_DES_192_CBC3_SHA 00 13 - EDH_DSS_DES_192_CBC3_SHA 00 0a - RSA_DES_192_CBC3_SHA 00 33 - DHE_RSA_WITH_AES_128_SHA 00 32 - DHE_DSS_WITH_AES_128_SHA 00 2f - RSA_WITH_AES_128_SHA 00 07 - RSA_IDEA_128_SHA 00 05 - RSA_RC4_128_SHA 00 04 - 00 15 - EDH_RSA_DES_64_CBC_SHA 00 12 - EDH_DSS_DES_64_CBC_SHA 00 09 - RSA_DES_64_CBC_SHA 00 14 - EDH_RSA_DES_40_CBC_SHA 00 11 - EDH_DSS_DES_40_CBC_SHA 00 08 - RSA_DES_40_CBC_SHA 00 06 - RSA_RC2_40_MD5 00 03 - RSA_RC4_40_MD5 01 - compression suite length 00 - no compression we can see that this is TLS1 cleint_hello with the same cipher suites as your first test with SSL2 (without SSL2 ciphers of course). read from 0xa4e8f0 [0xa53e98] (5 bytes = 5 (0x5)) - 15 03 01 00 02. read from 0xa4e8f0 [0xa53e9d] (2 bytes = 2 (0x2)) - 02 28 .( 4488:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:. \ssl\s3_pkt.c:1057:SSL alert number 40 4488:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:.\ssl\s3 _pkt.c:534: The error is different and I don't know why, where can I see the explanation of the error? I have get this from another answer that you have written in the past... alert 40 means that client was not able to negotiate an acceptable set of security services. In this situation this probably means that client does not support certificates with ECC parameters. but then, what can I do? Maybe is a wrong way on creating the certificate? I only need a certificate with a private key that accomplish one of this ciphers: (see the picture) in order to establish a https connection. http://www.nabble.com/file/5607/ciphersSoportadosPorVitria.jpg Hard to say what generate this error on your server ... but I've performed some tests on Linux (FC5) and all test was successful. First I've enabled SSL on Tomcat using only java tools and self signed certificate: - generating java keystore with self-signed certificate: # /usr/java/jre1.5.0_05/bin/keytool -genkey -alias tomcat \ -keyalg RSA -sigalg SHA1withRSA \ -keystore /usr/share/tomcat5/.keystore Enter keystore password: changeit What is your first and last name? [Unknown]: nx9010.malkom.pl What is the name of your organizational unit? [Unknown]: Malkom Admin What is the name of your organization? [Unknown]: Malkom What is the name of your City or Locality? [Unknown]: Warsaw What is the name of your State or Province? [Unknown]: Warsaw What is the two-letter country code for this unit? [Unknown]: PL Is CN=nx9010.malkom.pl, OU=Malkom Admin, O=Malkom, L=Warsaw, ST=Warsaw, C=PL correct? [no]: yes Enter key password for tomcat (RETURN if same as keystore password): # /usr/java/jre1.5.0_05/bin/keytool -list -v \ -keystore /usr/share/tomcat5/.keystore Enter keystore password: changeit Keystore type: jks Keystore provider: SUN Your keystore contains 1 entry Alias name: tomcat Creation date: Jan 13, 2007 Entry type: keyEntry Certificate chain length: 1 Certificate[1]: Owner: CN=nx9010.malkom.pl, OU=Malkom Admin, O=Malkom, L=Warsaw, ST=Warsaw, C=PL Issuer: CN=nx9010.malkom.pl, OU=Malkom Admin, O=Malkom, L=Warsaw, ST=Warsaw, C=PL Serial number: 45a8e69f Valid from: Sat Jan 13 15:03:11 CET 2007 until: Fri Apr 13 16:03:11 CEST 2007 Certificate fingerprints: MD5: FD:5A:12:A4:54:F3:1D:BE:9E:16:AF:EF:32:C5:F9:50
RE: Doing a DH key exchange between OpenSSL and MS CryptoAPI
I do call the OpenSSL DH crypto API's in my openssl client. But in my Microsoft CryptoAPI client, the way they show you how to do a DH key exchange seems like it only works between two MS CryptoAPI end points. CAPI to CAPI works. OpenSSL to OpenSSL works. I just can't get OpenSSL to CAPI to work. And I believe it has something to do with the Microsoft formatting of their keys when exported. So I was wondering if anybody here has had to develop an app that needs to interoperate with a CAPI client/server. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of karthik kumar Sent: Thursday, January 11, 2007 1:50 AM To: openssl-users@openssl.org Subject: Re: Doing a DH key exchange between OpenSSL and MS CryptoAPI if you want to use different keys then u can implement a DH key exchange calling the openSSL DH crypto APIs. Bind , i think uses the OpenSSL crypto APIs. On 12/20/06, Edward Chan [EMAIL PROTECTED] wrote: Has anybody done this? I can get it to work when both ends are the same. But I can't do it when they are different. I also notice the public key computed by CryptoAPI is 16 bytes larger than that computed by OpenSSL which I assume is due to some hdr information in the KEYBLOB that MS generates? Does anyone have any experience with CryptoAPI and getting it to work with OpenSSL? Thanks in advance, Ed
Re: SSLv23_method and TLSv1 client hello
Hello, I have a question about the creation of SSL contexts, client hello and zlib compression. For example, executing `openssl s_server -accept ... -key ... -cert ...` uses SSLv23_server_method by default. (note: I use openssl 0.9.8d) Connecting to this server using `openssl s_client -connect ...` seems not to use compression: Compression: NONE Expansion: NONE whereas `openssl s_client -connect ... -tls1` does Compression: zlib compression Expansion: zlib compression Yes, because when you use SSLv23_server_method() client sends SSL2 client_hello packet with information that it supports up to TLS1 (or SSL3 - depends on configuration). But in SSL2 client_hello there is no place for compression information and server (even if supports) do not use compression (because there is no such information from client). Is there a way to use one context (to be used both for accepting and establishing connections) that will (cmp SSL_CTX_new manpage, section SSLv23_method): - understand SSLv2, SSLv3, and TLSv1 client hello messages, - will send out TLSv1 client hello messages As far as I understand, this is needed to get compression. Using two different contexts, one initialized with TLSv1_client_method, the other initialized via SSLv23_server_method, is possible of course, but that tends to be a little tedious if both clients use the same key, certificate, crls, etc. Additionally, are there backward compability issues if I use TLSv1_client_method (assuming that 'most' of my peers use SSLv23_method() to create their SSL context)? Cheers Philipp __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Doing a DH key exchange between OpenSSL and MS CryptoAPI
On Sat, Jan 13, 2007, Edward Chan wrote: I do call the OpenSSL DH crypto API's in my openssl client. But in my Microsoft CryptoAPI client, the way they show you how to do a DH key exchange seems like it only works between two MS CryptoAPI end points. CAPI to CAPI works. OpenSSL to OpenSSL works. I just can't get OpenSSL to CAPI to work. And I believe it has something to do with the Microsoft formatting of their keys when exported. So I was wondering if anybody here has had to develop an app that needs to interoperate with a CAPI client/server. I've done some CAPI/OpenSSL interop. It is just a case of reading the relevant documents and converting between the key formats. CryptoAPI generally uses little endian format while OpenSSL uses BIGNUMs which can be converted to big endian format and from that to little endian. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Doing a DH key exchange between OpenSSL and MS CryptoAPI
Thanks for the reply. I've read the various MSDN documents concerning this, and I don't really see anything helpful. The support guy at Microsoft seems clueless and I'm still waiting to hear back from him. So putting aside how to do the conversions, is there no standard format that most crypto libs use? I've written apps with RSA BSAFE Crypto-C ME, and Certicom libraries and they all can do a DH key exchange with each other and OpenSSL nicely; it's just CAPI that is the problem. I'd rather like to avoid having to convert to MS's stupid format since they seem to be the one not playing nice with everyone else and because the client can be either a CAPI client, or OpenSSL client, and I think it would be ugly to have to send additional info indicating the crypto lib being used and then have a special case in the server to handle different libs differently. At the risk of asking too much, could you point me to where I can find more info on converting to and from the two formats used by OpenSSL and CAPI? The only thing I've seen on MSDN talks about the BLOB headers and stuff. That's all fine, I've figured all that out. And I'm left with the modulus (excuse me if the terminology is wrong) which I believe is what is being exchanged. Then converting from big to little endian or vice versa still doesn't work. Excuse me if I'm sounding a little desperate, but I am. I've scoured the MSDN docs. I've searched thru the OpenSSL mail archives, and I can't seem to find anything that helps, but this is obviously something that people have done. I tried making an https connection using WinInet to my OpenSSL server to see if I can debug the DH key exchange, but seems like it is doing RSA instead. If I disable RSA, the SSL handshake seems to fail, I think because the client won't do a DH key exchange. So I'm pretty much F'd at this point as to what to do next. Thanks, Ed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr. Stephen Henson Sent: Saturday, January 13, 2007 11:05 AM To: openssl-users@openssl.org Subject: Re: Doing a DH key exchange between OpenSSL and MS CryptoAPI On Sat, Jan 13, 2007, Edward Chan wrote: I do call the OpenSSL DH crypto API's in my openssl client. But in my Microsoft CryptoAPI client, the way they show you how to do a DH key exchange seems like it only works between two MS CryptoAPI end points. CAPI to CAPI works. OpenSSL to OpenSSL works. I just can't get OpenSSL to CAPI to work. And I believe it has something to do with the Microsoft formatting of their keys when exported. So I was wondering if anybody here has had to develop an app that needs to interoperate with a CAPI client/server. I've done some CAPI/OpenSSL interop. It is just a case of reading the relevant documents and converting between the key formats. CryptoAPI generally uses little endian format while OpenSSL uses BIGNUMs which can be converted to big endian format and from that to little endian. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
