Hi Dave, >>But even with that done/fixed in my test environment I DO get >>verify error 24 invalid CA cert depth 1 (my only intermediate). >>Is that what you're getting? If so, it looks like maybe the >>'purpose' checks have been made stricter since the last time >>I did this in test, where I have V1/noextension certs. >>I can't set up a test with real(er) (CA)certs immediately. >>If you have V1 or otherwise 'substandard' CA certs, you might >>try enhancing those.
Yes, I was getting the same error. And after using v3 certificates, the error did not appear again and my client-server app is working well with the multi-level configuration. Thanks a lot for your patient help in this regard. Regds, Ashok On Sat, Dec 3, 2011 at 4:17 AM, Dave Thompson <dthomp...@prinpay.com> wrote: > > From: Ashok C [mailto:ash....@gmail.com] > > Sent: Friday, 02 December, 2011 00:11 > > > Keeping the things you have mentioned in mind, this is how it goes. > > In server side, EE key is loaded using > > SSL_CTX_use_RSAPrivateKey_file(ctx,eekeyfile,SSL_FILETYPE_PEM); > > EE certificate is loaded using SSL_CTX_use_certificate_file(ctx, > > eepemfile,SSL_FILETYPE_PEM); > > And the intermediate certificate chain is loaded using > > SSL_CTX_use_certificate_chain_file(ctx, interchain) - This chain > > contains intermediate CA certs without the rootCA. > > In client side, rootCA is loaded using > > SSL_CTX_load_verify_locations(ctx,capemfile,NULL). > > After attempting SSL_connect from client, the intermediate > certificate > > chain and the EE certificate are received in client side using > > SSL_get_peer_cert_chain(ssl) and SSL_get_peer_certificate (ssl) > respectively. > > After this we call SSL_get_verify_result(ssl) which fails. > > So question here is that whether we need to add the received > > chain explicitly to the verify locations in client side? Meaning, > > do we need to build the chain from client side explicitly by ourselves? > > First, I made a mistake; it's been a long time since I coded this. > CTX_use_certificate_chain_file loads BOTH the entity cert (which > must be first in the file) AND the chain certs, and thus REPLACES > CTX_use_certificate_file. I'm guessing you have that data, > since if _use_certificate_chain_ doesn't contain the EE cert > then handshake can't select this auth type (and we have no other) > which produces a rather different (and less helpful!) error. > > But even with that done/fixed in my test environment I DO get > verify error 24 invalid CA cert depth 1 (my only intermediate). > Is that what you're getting? If so, it looks like maybe the > 'purpose' checks have been made stricter since the last time > I did this in test, where I have V1/noextension certs. > I can't set up a test with real(er) (CA)certs immediately. > If you have V1 or otherwise 'substandard' CA certs, you might > try enhancing those. > > These specific checks appear to be bypassed for certs in the > truststore, so putting all of the chain above the server EE > in the client truststore is an alternative (and works for me). > In that case the server only needs to send its EE cert (i.e. > only _use_certificate). This is typically more work to set up > and manage 'in the wild', but it is an alternative. > >
