> 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
