>       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