Re: when does a server need to use SSL_CTX_set_client_CA_list()?

Garrett Wollman wrote:
>Rick Macklem writes:
>>Since it is done in sample code, I have an option in the RPC-over-TLS
>>server daemon that does the SSL_CTX_set_client_CA_list() call.
>>When I test, I have not used this option and the code seems to work.
>>Maybe this is because the client only has a single certificate?
>
>In general, the server needs to send a list of CAs that it's willing
>to accept for client certificate use, because the server should never
>accept just any old CA; normally, a client will interpret receiving
>the list as a request to send a client certificate issued by one of
>the indicated CAs, but the client can send its certificate even if the
>server doesn't send the list or even if the server sends a list but
>client certificate isn't issued by a CA on the list.
>
>It's probably a good idea to send the list even if there's only a
>single valid CA, configured by prior agreement; the overhead is
>minimal and it gives an indication to a fussy or confused client what
>is being required of it.
Ok, so does SSL_CTX_load_verify_locations() set up the server to verify
the certificates and SSL_CTX_set_client_CA_list() set the list of certificate
names sent to the client?

Put another way, should the server normally:
SSL_CTX_load_verify_locations(ctx, cafile, NULL);
and
SSL_CTX_set_client_CA_list(SSL_CTX_load_client_CA_file(cafile));
where cafile is the file with the CA certificates in it?

I currently have the server setting these via separate options and only do the
first one.
If they both use the same file, then I can simplify things and get rid of one of
the options.

Thanks for your help with this, rick

>My recollection is that in the OpenSSL API in particular, if you don't
>set an explicit client CA list, but you *do* set a CA bundle or
>directory to automatically construct the *server's* trust path, then
>the library will just send the name of every single CA it knows about.

-GAWollman