Hi Dave, Thanks for the reply. 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. 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? To be more clear, is there any option in which we can use CAPath to "send" certificates? >>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. On Tue, Nov 29, 2011 at 9:51 AM, Dave Thompson <dthomp...@prinpay.com>wrote: > > From: owner-openssl-us...@openssl.org On Behalf Of Ashok C > > Sent: Monday, 28 November, 2011 00:35 > > > One more question 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 . > > Similar but less obvious, if you use client auth (i.e. client > presents cert) the CA name(s) "requested" in the CertRequest > are separate from the CA cert(s) actually used for verification. > Often you want to make these the same, but it's not automatic. > Use SSL_[CTX_]set_client_CA_list or SSL_[CTX_]add_client_CA . > > > P.S. My previous query also is unanswered. It would be great > > if I get some responses to that also ;) > > > From: Ashok C <ash....@gmail.com> > > Date: Wed, Nov 23, 2011 at 12:55 PM > > > We are implementing multi-layer support for our openssl-based > > PKI solution and had the following query: > > The usual term for what I think you mean is multi-LEVEL CAs, > or hierarchical CAs. > > > Currently our PKI solution supports only single layer CA support > > and we use SSL_CTX_load_verify_locations API with the CAFile option, > > meaning that the service loads the CA certificate from a PEM file. > > When testing multi-layer support between a client-server model > > with SSL_VERIFY_PEER set to true, we observed that using the CAFile > > (with all CA certificates- root + intermediate concatenated into > > a single PEM file) does not work anymore. But using CAPath option > > (storing each CA in separate file, creating hashes for them in a > > directory and providing that directory in CAPath) seems to work fine. > > Is this a known bug with openSSL or is it something that we are doing > wrong. > > 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? > > 2. What exactly are you testing, and what exactly is the error(s)? > Can you reproduce it with commandline s_client and/or s_server? > > 3. For SSL/TLS it is common, but not universal, for the server to > provide in its handshake all intermediate CA certs, and similarly > for the client to do so if client-auth is used. If all peers of a > relier do this it doesn't need to configure any intermediate certs, > only the root(s). This is often more convenient, since for (some? > many?) public CAs the intermediates tend to change more often, and > the entity that gets a cert from the CA may be the first to know. > You don't say if your 'solution' uses public CAs or your own CA(s); > if the latter presumably the behavior is more under your control. > > If you are using OpenSSL cert verification (and perhaps other functions) > for some other protocol/application/whatever, answer may be different. > > 4. It's not clear to me if it's standard, but OpenSSL always verifies > up to a root in the truststore, even if a lower intermediate cert is > also in the truststore. This is the same for CAfile and/or CApath. > > > Also, from the openSSL community perspective, is it advisable > > to use CAFile option or CAPath option when providing multi-layer support? > > Maybe. See above about which CA certs to configure. > > If you mean a choice between CAfile and CApath, it's up to you. > As far as the code goes the only differences are: > > - CAfile is read once, when you call _load_verify, and kept in > memory. It is not updated, unless your program calls again. > The memory it uses is rarely an issue on desktop class devices > unless you have millions of CA certs, but might be on smaller > e.g. mobile devices, but you probably don't use OpenSSL there. > Any format error in the file is detected at load time. > > - CApath is read when needed, during handshake. If your program > runs more than a short time and makes or accepts new connections > you can get dynamic updates. If your program handles a very high > rate of handshakes this could be a performance issue. Any format > error may not be detected until a handshake uses that cert. > > One caveat: the hash used for CApath names changed between > 0.9.8 and 1.0.0. If you need to support systems or users > on both 'families', that may be a bother. > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org >
