[openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

[Kurt Roeckx]

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-bounces at openssl.org] On Behalf Of Nounou Dadoun
> Sent: Thursday, February 25, 2016 5:44 PM
> To: openssl-users at 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-bounces at openssl.org] On Behalf Of Nounou Dadoun
> Sent: Thursday, February 25, 2016 2:42 PM
> To: openssl-users at 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