Accidentally sent privately, copying to list for anyone else interested > From: Dave Thompson [mailto:dthomp...@prinpay.com] > Sent: Friday, 02 December, 2011 17:47 > To: 'Ashok C' > Subject: RE: Usage of CAPath/CAFile options in int > SSL_CTX_load_verify_locations Reg. > > > 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. >
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
