Hello Dave,
Thanks for this info.
I compiled my own openssl lib with debug support and started debugging.
The problem seems indeed to be located in the call to
X509_STORE_CTX_get1_issuer. In this function, the function
X509_STORE_get_by_subject returns an error. When digging into this
code, the following loop is executed once :
for (i=vs->current_method; i<sk_X509_LOOKUP_num(ctx->get_cert_methods); i++)
In the only iteration it performs, the function
sk_X509_LOOKUP_value(ctx->get_cert_methods,i) returns a struct
initialised with "by_file.c" X509 handler, which looks like this :
X509_LOOKUP_METHOD x509_file_lookup=
{
"Load file into cache",
NULL, /* new */
NULL, /* free */
NULL, /* init */
NULL, /* shutdown */
by_file_ctrl, /* ctrl */
NULL, /* get_by_subject */
NULL, /* get_by_issuer_serial */
NULL, /* get_by_fingerprint */
NULL, /* get_by_alias */
};
Thus, the call to X509_LOOKUP_by_subject fails as the provided handler
does not support this method.
>From that point, I am a little stuck... I do not see any error in the
"SSL_CTX_load_verify_locations" function call that would explain why
my store is initialised with a handler that does not support
"get_by_subject" method, and I do not find any reason why the call to
X509_STORE_CTX_get1_issuer chooses this method instead of another. So,
I really find no may to avoid this problem.
I have the feeling that, if I use the "CApath" field instead of the
"CAFile" field of function "SSL_CTX_load_verify_locations", this could
solve my problem, as the "by_dir.c" supports the get_by_subject but :
- I have no idea on how to initialise a directory with proper files
(in production, I will have a PEM file containing more than one
certificate)
- I suppose there should be a way to use openssl like I am doing now...
Any help would be higly appreciated, as I am currently completely stuck...
Thanks in advance,
Brice
2013/5/31 Dave Thompson <dthomp...@prinpay.com>:
>> From: owner-openssl-us...@openssl.org On Behalf Of Brice André
>> Sent: Thursday, 30 May, 2013 04:08
>
>> I tested [s_client] and it seems to work properly, which, I
>> suppose, means that the problem resides in my client code. I
>> copy-pasted the output below.
>>
> I think so; see more below.
>
>> I just find something strange on the server : to write my server code,
>> I followed a tuto where they initialised a diffie-helman key in the
>> server side. I was not sure of the utility of that and thus, I
>> performed several tests with the command you provided : with and
>> without this initialisation on the server side. In both cases, this
>> works properly. So, I am a little bit confused about that. I would
>> want to remove that part, but I am not sure if it may be useful...
>>
> I presume you mean *temporary* Diffie-Hellman *parameters* i.e.
> SSL_CTX_set_tmp_dh (or _callback). The actual key using those
> parameters is generated inside openssl. This is for ciphersuites
> using "ephemeral" or "anonymous" DH key-exchange, abbreviated
> EDH or DHE (better to avoid confusing EDH with ECDH which is
> different) and ADH. SSL/TLS also defines ciphersuites using
> static Diffie-Hellman, but openssl does not implement them;
> plus you can't have a selfsigned cert for a (static) DH key.
>
> Your key is RSA so s_client by default and your client as posted
> supports both ciphersuites with DHE (DHE-RSA) and without (RSA, or
> akRSA to avoid ambiguity). Other kinds of key/cert would differ.
> I believe (but didn't check) that both will prefer DHE-RSA; thus
> you might observe the difference if either endpoint displays
> SSL_get_cipher_name(ssl) or equivalent after handshake, or
> when you use s_client which displays this among other things.
>
> The advantage of DHE-RSA over akRSA is "perfect forward secrecy":
> assuming the endpoints (together) put sufficient entropy into
> their DHE keys, the session keys cannot be recovered and thus
> logged session data cannot be decrypted even if the (server's)
> privatekey is later compromised. Google for more. In a situation
> where you're doing both endpoints (no interop) and trust your
> own key management, PFS probably doesn't have any benefit.
>
>> I joined my client code. The interesting function is
>> "wxSSLSocketClient::InitiateSSLSession". This code uses the wxWidgets
>> library and thus, it uses the wxSocketClient (wxWidgets socket
>> implementation) with a dedicated BIO so that openssl can handle it.
>> This code is extracted from the wxEMail project (I am the maintaniner
>> of this project). But, in this project, I did not implement the server
>> certificate check stuff. Thus, this version is slighlty modified to
>> perform those additional checks.
>>
>> You will easily identify which part is original code and which one is
>> not because original code was designed to work in static link as well
>> as dynamic link (with a manual load of library). So, in original code,
>> all ssl calls are encapsulated in a macro. The modified version
>> currenlty only support static link, and thus ssl calls are not
>> encapsulated in the macro.
>>
> It's a bit difficult to read through the clutter, but I don't see
> anything here which should cause the cert lookup to fail. If some
> calls were going to a different version openssl library(ies) somehow
> that might explain it, but with OPEN_SSL_STATIC_LINK defined
> I don't see how that would happen.
>
> Two things I do notice:
>
> - SSL_set_connect_state is redundant when using SSL_connect.
> (It is needed for "transparent" or "automatic" handshake.)
>
> - SSL_set_cipher_list "ALL" includes the anonymous suites that
> provide no authentication, which may conflict with your goal.
> Do you want your client to verify the server unconditionally, or
> only if the server "agrees" by choosing an authenticating suite?
>
>> Note that this code allows performing ssl connection on different
>> servers and thus, I really think that the BIO part and so on is OK.
>> The only part that has never been tested is the new part performing
>> the server certificate check.
>>
>
> I think you're down to an ordinary debugging problem here.
> In your shoes I would:
>
> - cut down the code to the minimum that reproduces the problem;
> your special BIO logically shouldn't matter, but cut it out
> anyway to be certain and simplify the code
>
> - use a (re)build with symbols and step through it using a good
> debugger (preferably gdb); in particular, after _load_verify
> ctx->cert_store->objs->stack should have num=1 (and data should
> point to a pointer that's actually to an X509_OBJECT that contains
> a pointer to the desired cert, but that's harder to look at),
> and the first time you get to X509_STORE_CTX_get1_issuer from
> X509_verify_cert for this case ctx->ctx->objs->stack the same.
> (The first ctx is a store_ctx and the second actually a store,
> which is confusing.) If not then backtrack to see why not; if so
> then step forward to see why it's not matched and accepted.
>
> - if I get to a point where what the debugger says happened
> is not what the source code directs, look at the machine code
> and registers etc. as needed. This is a last resort.
>
> Good luck.
>
> <snip>
>> D:\home\DbSync1>C:\OpenSSL-Win32\bin\openssl s_client
>> -connect localhost:1212 -CAfile server.crt
>> Loading 'screen' into random state - done
>> CONNECTED(00000738)
>> depth=0 C = BE, ST = Hainaut, L = Charleroi, O = AMS-Solutions,
>> CN = Brice Andre, emailAddress = brice.an...@xxx.be
>> verify return:1
> <snip most>
>> New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
>> Server public key is 2048 bit
>> Secure Renegotiation IS supported
>> Compression: NONE
>> Expansion: NONE
>> SSL-Session:
>> Protocol : TLSv1
>> Cipher : DHE-RSA-AES256-SHA
> <snip rest>
>
> If the server doesn't have a temp-DH key (or callback) this ciphersuite
> won't be the one selected. You'll get RSA-something, almost certainly
> RSA-AES256-SHA, instead.
>
>
> ______________________________________________________________________
> 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
