Hi,
After lot of struggles, finally get rid of this error, but I cant tell the reason, how was it rectified. We installed our libs on a new machine. Now a different error is seen. After client and server conection is established, TLSv1 Encrypted Alert+21 is sent by the client. Google search did not help. All I could find out was, error alert is encrypted. Did not understand what condition was seen by client's openssl to throw this error and how to know the condition? Any inputs on this. Dave Thompson-5 wrote: > >> From: owner-openssl-us...@openssl.org On Behalf Of pradeepreddy >> Sent: Thursday, 12 May, 2011 18:37 > >> I have tried with all the ciphers. This same application works well on >> windows. >> >> I run my application again with s_server, but hit with the same error: >> SSL_ERROR_SSL >> error:140D308A:SSL routines:TLS1_SETUP_KEY_BLOCK:cipher or >> hash unavailable >> >> And on s_server [with -msg -debug], folwing messages are : >> >> client hello >> server hello >> SSL_accept:SSLv3 write certificate A >> >>> TLS 1.0 Handshake [length 0004], ServerHelloDone >> 0e 00 00 00 >> SSL_accept:SSLv3 write server done A >> SSL_accept:SSLv3 flush data >> SSL_accept:failed in SSLv3 read client certificate A >> ERROR >> shutting down SSL >> CONNECTION CLOSED >> SSL_accept:failed in SSLv3 read client certificate A > > Both -msg and -debug should have given you (redundant) > hex dumps of all messages; did you delete them? > But only -state, which you didn't say you used, should give > lines like 'SSL_accept:SSLv3 write server done A' . > > If there is no ServerKeyExchange (you didn't just delete it) > then the selected suite probably uses RSA key agreement. > But that doesn't help much; there are kRSA suites with > all or nearly all data-ciphers and several hashes. > > You can decode the dump of client-hello to determine what > list of suites (and compressions) the client is offering, > and of server-hello to determine what the server selected. > If you can install wireshark from www.wireshark.org on a > personal Windows machine that sees the same network link, > that can do the decode for you automatically. > There may be equivalent tools for Unix, but I don't know. > >> This mean, client and server are agreed on cipher. In what >> cases client >> verifies the TLS1_SETUP_KEY_BLOCK? which drove client to >> throw this error? >> > It's not a matter of verifying. The client is trying to > *do* setup for the selected suite, and also compression, > and failing. "Key" setup is a slightly misleading name; > it's actually setting several internal pointers as well as > the actual keys, and this first step -- determining pointers > effectively to code for the selected cipher, hash, and > compression -- is what is failing. > > Most likely the client has offered a suite or compression > it doesn't actually support, which it shouldn't, or some of > OpenSSL's memory has been clobbered by a bug in your client. > > Look at the selected suite in server-hello, and compare > to the build options for the build(s) you are using. > > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org > > -- View this message in context: http://old.nabble.com/Application-is-failing-with-cipher-or-hash-unavailable-tp31597508p31628139.html Sent from the OpenSSL - User mailing list archive at Nabble.com. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
