Dave, thanks so much for your response.
I really was on the verge of giving up on this.
Let me start by saying that it is solved. You gave the hint that made the
difference. Also, you let me understand more what was going on. You have
pointed out some apparent mistakes that were indeed caused by copy and
pasting and on several occasions editing stuff to omit sensitive
information. What really made the difference was this:
On Tue, Jun 11, 2013 at 9:12 AM, Dave Thompson <dthomp...@prinpay.com>wrote:
> > SSL_CTX *ctx = m_ssl_context.impl();
> > SSL *ssl = m_ssl_socket.impl()->ssl;
>
> Is an SSL pointer actually set here? See below.
>
Yes. Asio wraps it in a ssl_socket type object. I can access it any time.
Which turned out to be a hint towards the real problem. See below.
> int res = 0;
> res = SSL_CTX_use_certificate_chain_file(ctx, "myca.crt");
> if (res <= 0) {
> // handle error
> }
> This is (almost certainly) not the analog of load_verify_file.
> You want SSL_CTX_load_verify_locations (ctx, "myca.crt", NULL)
> to set a CAfile and no CApath. However, I'm surprised this
> didn't cause the client to reject the server before even
> attempting to authenticate itself (during handshake) --
> unless you have set or defaulted it somewhere else,
> or put in a callback that overrides the verify error.
>
> _use__chain_file of (only) a CA cert is completely wrong,
> but fortunately immediately overridden by your next call.
>
> > res = SSL_CTX_use_certificate_file(ctx, "testclient.crt",
> SSL_FILETYPE_PEM);
> > if (res <= 0) {
> > // handle error
> > }
> > res = SSL_CTX_use_PrivateKey_file(ctx, "testclient.key",
> SSL_FILETYPE_PEM);
> > if (res <= 0) {
> > // handle error
> > }
>
> Those two calls, assuming no error, should have caused libssl to send
> the client cert (and the chain=root if available) and use the key --
> as long as they occur before the SSL object is created from the SSL_CTX,
> and no subsequent calls modify these settings in the SSL object.
>
That's the point. As long as the SSL object is created _after_ the context
was modified. That was not the case. The asio code created the context and
the socket upon it (that wraps the ssl*) in the initializer list, pretty
much making all my modifications afterwards obsolete. As they were all in
the c'tor. My server code did it right but the client was wrong. I have
verified it by replacing the SSL_CTX_something(ctx...) functions with
SSL_something(ssl... ) and now it works just fine. I will restructure it to
reflect this and try to get back to the asio versions so I don't have to
bypass that layer but in any case, it works.
I can now use the SSL connection and client certs and everything. The magic
silver bullet indeed. And I have to say, at least in this version asio
almost encourages this mistake in my opinion. Also, there's no equivalent
SSL_something() functions on the socket like OpenSSL has, only the ones on
the context and they were always ignored. Also, there's nothing in asio's
docs hinting at this essential fact.
Well, I can utter a huge sigh of relief now and than you very much for your
help.
Cheers,
Stephan
