RE: Usage of CAPath/CAFile options in int SSL_CTX_load_verify_locations Reg.

[Ashok C]

Hi,

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?
P.S. My previous query also is unanswered. It would be great if I get some responses to that also ;)

Regds,
Ashok

---------- Forwarded message ----------
From: Ashok C <ash...@gmail.com>
Date: Wed, Nov 23, 2011 at 12:55 PM
Subject: Usage of CAPath/CAFile options in int SSL_CTX_load_verify_locations Reg.
To: openss...@openssl.org

Hi,

We are implementing multi-layer support for our openssl-based PKI solution and had the following query:

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.

Also, from the openSSL community perspective, is it advisable to use CAFile option or CAPath option when providing multi-layer support?

 

Regds,
Ashok

[Dave Thompson]

> From: owner-ope...@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 openss...@openssl.org
Automated List Manager majo...@openssl.org

[Ashok C]

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.

[Dave Thompson]

> From: owner-ope...@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++).

[Ashok C]

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

[Ashok C]

Hi Dave,

>>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.

Yes, I was getting the same error. And after using v3 certificates, the error did not appear again and my client-server app is working well with the multi-level configuration. Thanks a lot for your patient help in this regard.

Regds,
Ashok

On Sat, Dec 3, 2011 at 4:17 AM, Dave Thompson <dtho...@prinpay.com> wrote:

>       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.