I have an app that uses openssl to connect to a server on a different machine. In one case on my Ubuntu machine the app has no problem getting a secure connection. But when I recompile the same app for an embedded target board and run it I get this error: # ./client3 192.168.1.99 Enter PEM pass phrase: connecting to 192.168.1.99:16001 ** client3.c:77 Error connecting SSL object 1024:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278: 1024:error:1408D07B:SSL routines:ssl3_get_key_exchange:bad signature:s3_clnt.c:2004: The app uses the same private key and certificate in both cases. As a test I used s_client on both platforms to see whether it's a problem with the app, and it too fails with the same error on the embedded target but makes a connection on the Ubuntu machine....just like the app. Something I observed on a wireshark trace is that depending on what platform the app is running on, in the 'Client Hello' exchange the app advertises a much smaller set of cipher suites on the Ubuntu machine than on the embedded target app. Consequently the server chooses a different cipher suite in both situations. This puzzles me and not sure if it's related to my problem. Worth noting the version of openssl on the Ubuntu machine which is the platform that works, is older than the version for the embedded target board. Not using TLSv2. Appreciate any help or a nudge on how to debug this. /carl h. *** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***
