Curiouser and curiouser - I have attached two minimal packet captures in which
the only difference in the server build was a change in one line (using boost
with openssl):
: m_context(pIoService->GetNative(),
boost::asio::ssl::context::tlsv1)
to
: m_context(pIoService->GetNative(),
boost::asio::ssl::context::sslv23)They both disable sslv2 and sslv3. The former resulted in a handshake that completed, the latter failed with the aforementioned "67702888--bad signature" logged error. The respective packet captures are attached. This one has me pretty puzzled, any idea why tls1 succeeds and tls1.2 fails? Is tls1.2 more strict about accepting the client certificate since it's complaining about a "bad signature" where tlsv1 doesn't? Anybody have any ideas? ... N Nou Dadoun Senior Firmware Developer, Security Specialist -----Original Message----- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Nounou Dadoun Sent: Thursday, February 25, 2016 2:42 PM To: openssl-users@openssl.org Subject: [openssl-users] Failed TLSv1.2 handshake with error 67702888--bad signature I'm trying to troubleshoot some development code which is enabling TLSv1.1 and 1.2 and failing. Have an odd tls handshake failure, with an error number that I can find any documentation about (is there any?) that indicates "67702888--bad signature" which is being logged on the server side; and I'm trying to see where in the handshake things are falling apart. Looks like it's negotiating tls1.2 and agreeing on TLS_RSA_WITH_AES_256_CBC_SHA256 but the client seems to be sending a certificate although I don't see it requesting mutual authentication. I've attached a very short wireshark capture - does anyone know what that error code might be related to or can give me a hint as to what's going awry here? Thanks ... N Nou Dadoun Senior Firmware Developer, Security Specialist Office: 604.629.5182 ext 2632 Support: 888.281.5182 | avigilon.com Follow Twitter | Follow LinkedIn This email, including any files attached hereto (the "email"), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide.
tlsv1_successful_handshake.pcapng
Description: tlsv1_successful_handshake.pcapng
tlsv1.2_failed_handshake.pcapng
Description: tlsv1.2_failed_handshake.pcapng
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
