I've extracted the certificates from the exchange to verify that the (tlsv1) successful handshake and the (tlsv1.2) failed handshake certificates are identical (they are) and I've also checked to make sure that the CA certificate that the server has for signature verification is the same as the CA certificate handed over by the client in the exchange (it is).
I've also used the command line openssl verify to verify the certificate against the CA: "client_cert_success.pem: OK" However it succeeds in TLSv1 and fails in TLSv1.2 (the one line change noted below). I've now attached the certificates for quick reference - can anyone see what might be causing the different behavior between TLSv1 and TLSv1.2? Quite puzzling! Nou Dadoun Senior Firmware Developer, Security Specialist -----Original Message----- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Nounou Dadoun Sent: Friday, February 26, 2016 9:34 AM To: openssl-dev@openssl.org Subject: [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature 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.
client_cert_success.pem
Description: client_cert_success.pem
client_cert_CA_success.pem
Description: client_cert_CA_success.pem
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
