Hi Dave,

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?

Regds,
Ashok

On Fri, Dec 2, 2011 at 5:33 AM, Dave Thompson <dthomp...@prinpay.com> wrote:

> >       From: owner-openssl-us...@openssl.org On Behalf Of Ashok C
> >       Sent: Wednesday, 30 November, 2011 00:51
>
> >       Some more followup questions here:
> >         In case of a server application, it is expected to send
> >       > the intermediate certificates to the client. And in this case,
> >       > is this API -- SSL_CTX_load_verify_locations(
> >       ) sufficient to be used?
> >       > Or is there a separate API to send the intermediate CA
> certificates
> >       > across to the client?
>
> >       >>>No, certs to *send* are separate from verifying *received*.
>
> >       >>>Yes, SSL_CTX_user_certificate_chain_file or
> SSL_CTX_add_extra_chain_cert .
>
> >       So, in this case certificates to be "sent" need to sent only
> > using the use_certificate* APIs., among which none of them take
> > CAPath as an input.
>
> That's not what I said. _use_certificate[_ASN1|file]
> (but NOT _use_certificate_chain_file) is used to provide
> an entity's own certificate. It is always sent if
> authentication is used for this entity in the handshake
> (for server usually, for client sometimes).
>
> _use_certificate_chain_file (not 'user', my typo, sorry)
> or _add_extra_chain_cert may be used to specify chain
> or intermediate certs. They are added to the Cert message
> if authentication is used for this entity.
>
> > In this case, how does the s_server/s_client implementation
> > work with -CAPath options? Internally does it use just
> > load_verify_locations(*,CAPath) ? Or does it translate
> > the hashes present in CAPath to X509 objects and then
> > use the use_certificate* APIs?
>
> s_server and s_client call _load_verify_locations, which uses
> CAfile and/or CApath to verify subsequently received cert(s).
> It does NOT use them as own (entity) or chain certs.
>
> >       To be more clear, is there any option in which we can use
> > CAPath to "send" certificates?
>
> No. CApath within OpenSSL is only used for verifying received cert(s).
>
> s_server and s_client do not have any feature to send chain certs.
> They are only test/sample programs; if you want something different,
> use your own program (perhaps based on them, if you wish).
>
> >       >>1. I doubt there's a bug in OpenSSL here; this is very widely
> >       >>used functionality; both CAfile and CApath have worked for me
> >       >>in all versions I've used. What version(s) are you running,
> >       >>is it vanilla build or any mods/patches, and built how?
>
> >       We are running openssl-0.9.8g and 1.0.0d in normal x86/x86_64
> > environment with few CVE patches.
>
> I still have 0.9.8g builds (and other 0.9.8) around for support.
> On Solaris/sparc, Linux/x86, and Windows/x86 both CAfile and CApath
> work equivalently and as expected. 1.0.0c also works on all,
> and 1.0.0e on the first two (haven't done 1.0.0e on Windows
> because no longer needed on the systems I support).
> I don't do specific x86_64 builds, we just run x86 code on those
> machines, but I can't imagine this would be an ISA-dependent bug.
> (As opposed to some crypto primitives like AES and SHA1, which do
> have different assembly code -- but are also very well tested.)
>
> As I asked before, can you reproduce with s_server and s_client?
> If so, post exact files (using a throwaway key) and we can
> try to look at it (although the X509-store/lookup stuff is
> in my opinion among the most confusing part of OpenSSL code).
>
> If it only occurs in your program(s), I suspect your program(s).
> One idea springs to mind: as I said CAfile is read into memory
> and kept there while CApath is read from disk when needed,
> so maybe something in your program is clobbering memory.
> That's a very common mistake in C (and C++).
>
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    openssl-users@openssl.org
> Automated List Manager                           majord...@openssl.org
>

Reply via email to