Do you still see an error if you specify one cipher? f.e. AES256-SHA?
On 2013-11-07 22:26, Dave Thompson wrote:
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
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
