I can only find 1 place in the server that generates an SSL_R_BAD_SIGNATURE and that's in ssl3_get_cert_verify, in the case of signature algorithms are used, which is new in TLS 1.2.
I don't see anything obviously wrong, and as far as I know the test suite also tests client authentication. Kurt On Fri, Feb 26, 2016 at 05:34:16PM +0000, Nounou Dadoun wrote: > Trying to upgrade from TLSv1 to TLSv1.1 and 1.2 has been more problematic > than I might have suspected. > I have a TLS server using openssl 1.0.2d doing mutual authentication and a > one line change from TLSv1 (only) to TLSv1.2 breaks the connection where in > the latter the server rejects the client certificate with "error > 67702888--bad signature" (and the former happily accepts it). > > Given that description (and the fact that it's literally a one-line change), > it's hard to believe that I'm doing something wrong. > > Can anyone tell me why TLSv1 accepts it and TLSv1.2 doesn't? Packet capture > attached and more details below, certificate is in the packet capture but I > can provide it separately if it will help, thanks ... 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 5:44 PM > To: openssl-us...@openssl.org > Subject: Re: [openssl-users] Failed TLSv1.2 handshake with error > 67702888--bad signature > > 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-us...@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. > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
