> From: owner-openssl-users On Behalf Of Viktor Dukhovni > Sent: Thursday, November 07, 2013 11:02
> On Thu, Nov 07, 2013 at 12:29:13PM +0000, Ben Arnold wrote: > > > I am using SSL_CTX_set_client_cert_cb to provide the client > > certificate when needed. I have a problem in that OpenSSL 1.0.1e > > does not trigger this callback for all websites that I expect it > > to, only some. Instead on the failing sites there is an SSL > > handshake failure after the client verifies the server certificate: > > You can test with s_client(1) and compare results. Is your client > certificate an RSA certificate? How many bits of public key? Is > its signature SHA1 or SHA256? > OP's log shows protocol hasn't reached the CertReq -> ClientCert steps so at this point nothing about the client cert should matter. (And in any case the signature *on* the cert is by the CA key, unless it's self signed, in which case using it for client-auth would be really silly. From the log, unless OP "fixed" it, the server cert looks like a DIY CA, and if someone does that for the server I would expect it for clients also.) To OP: is the logged server cert info true? I note the log shows the client verification of the server failed; did this website give you a "custom" root to trust and did you simply not set that up (or perhaps not in the environment you're testing in)? > > SSL read: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake > > failure, errno 0 > > > > Interestingly if I compile against 1.0.0k then there is no failure > > and the callback *is* triggered for all sites (that I have tried > > so far anyway). > > Sounds like a problem with TLSv1.2. If your client certificate is > only 512-bits it may not be wide enough to sign a SHA384 digest, > or some other TLSv1.2 parameter issue. > Client hasn't even selected the cert yet. And although I agree a PCAP is better in general than a less-complete program log, just looking at the headers in the log you can see the client offered TLSv1.2 (0303) but the server only accepted TLSv1 (0301) so there definitely isn't any SHA-2 issue. But something else related to TLSv1.2 does seem likely. Possibly the new larger size (as OP observed), or the new extensions, although the initial negotiation apparently worked fine with both. > Attaching a PCAP file of the traffic is much more useful than hex > packet dumps. Capture the traffic with "tcpdump -s0 -w file ..." > and look with "wireshark -r file". If you don't understand the > wireshark output, post the (binary) PCAP file containing just one > failed TLS handshake, perhaps also a PCAP file with a succesful > TLS handshake. > I do notice the second ClientHello -- in response to server request -- using 1.0.1 re-offers TLSv1.2. I thought it was good practice when we know the server has previously rejected something not to re-offer it, but I don't recall where I saw this and I might well be wrong. Even so the server should negotiate down (as it did initially) or at minimum send an alert, not just close. To OP: If you can try to reproduce with s_client default (which is TLSv1.2 or less) and again specifying -tls1 (or -no_tls1_2 -no_tls1_1). That might narrow it down pretty close. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
