Dear Dave, Thanks for your help.
I solved my problem and I am very ashamed... I tried with the ssl client command line of my freshly compiled openssl version and got the same error. After investigation, I realised that the official windows binary client failed too. Thus, I was wondering why it worked a few days before and realised that, when I performed this test first, I downloaded my server certificate directly from my server, whilst when testing it today, I took the certificate used by my C++ client application. After a small check, I realised that this C++ client certificate was corrupted. So, I think that my first problem was the initialisation of the cert store, but you helped me solving it a few days before. But, in the mean time, when investigating my problem, I probably did a mistake that corrupted the copy of my certificate located on the client side (client and server are not on the same computer). As the error was the same, and as this error let me think that the problem was linked to the fact that the certificate was self-signed, I did not realise this stupid thing. Sorry to have bothered you with such stupid problem. Regards, Brice 2013/6/1 Dave Thompson <dthomp...@prinpay.com>: >> From: owner-openssl-us...@openssl.org On Behalf Of Brice André >> Sent: Friday, 31 May, 2013 06:00 > <snip> >> 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++) > [and does nothing because by_file method handler is null] > > You've already gone too far. See next. > >> 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. >> > by_file and by_dir work differently: > > If you call SSL_CTX_load_verify_locations thence X509_STORE_load_locations > with CAfile, it puts the by_file "lookup" method in the store and also > reads the file, converting all the certs and CRLs to in-memory structures > in store.objs which is a STACK_OF(X509_OBJECT) under your SSL_CTX. > When the handshake occurs and X509_verify_cert via _get1_issuer calls > X509_STORE_get_by_subject using that store, the second statement is > tmp=X509_OBJECT_retrieve_by_subject(ctx->objs,...) which is hard to > debug at least on my machine because it is inlined but should find > the loaded cert in .objs, so a few lines later if(tmp==NULL...) > skips over the loop you looked at and found to be ineffective. > > If you use CApath, _load_locations just puts the by_dir lookup method > in the store. At verify time, X509_STORE_get_by_subject finds nothing > in store.objs, so the loop does call the by_dir get_cert_by_subject > routine which looks in the specified dir(s) for a suitable file. > >> 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... >> > If you do want to use CApath & by_dir, choose or create a directory, > put each cert or CRL you want in a separate PEM file there and either: > - name each file <subjecthash>.<n> for a cert where subjecthash is > calculated by x509 -subject_hash and <n> is the 0 for the first > or only cert with that hash and 1,2... etc for any duplicates, or > <issuerhash>.r<n> for a CRL with crl -hash and 0,1,2... similarly. > - name each file anything you like such as FredServer.cer and create > a symlink to it using the hashname as above > - Windows doesn't have symlinks that people can use (although NTFS > does internally) so you must use the first method > - Unix does have symlinks and if you want the second method there is > a script c_rehash which goes through and computes and creates > the hashnamed links for you. > - the manpage for SSL_CTX_load_verify_locations has some of this > >> Any help would be higly appreciated, as I am currently >> completely stuck... >> >> Thanks in advance, >> Brice >> >> 2013/5/31 Dave Thompson <dthomp...@prinpay.com>: > >> > - 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. >> > > Thus I proposed you check that _load_verify_(ctx,CAfile,) > successfully gets the cert into store.objs in the sslctx, > and it's still in that store when lookup needs to find it. > > > ______________________________________________________________________ > 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
