Re: [ssl-users] Client Certificates in Communicator 4.5

[Dr Stephen Henson <[e-mail]>]

Bodo Moeller wrote:
> 
> Dr Stephen Henson <[e-mail]>:
> 
> It's not simply a "provision" to do so, in fact the server is even
> obliged to send the list.  The relevant definition (from
> draft-ietf-tls-protocol-06.txt, but it's the same in the early SSL 3.0
> specs) is
> 
>     struct {
>         ClientCertificateType certificate_types<1..2^8-1>;
>         DistinguishedName certificate_authorities<3..2^16-1>;
>     } CertificateRequest;
> 
> <3..2^16-1> means that the list of certification authorities is at
> least 3 octets, at most 2^16-1 octets long -- i.e. may not be empty.
> I think that SSLeay will send an empty list when
> SSL_CTX_set_client_CA_list has not been called, but it is asked to
> demand client certificates anyway.  SSLeay-based software that
> behaves in that way is in violation of the specification.
> 

Yes it does violate the SSL spec in this sense but nevertheless
Communicator versions before 4.06 permitted this and client auth worked
fine with an empty list. MSIE and Communicator 4.06 and later offer a
choice from the supplied list and give rather misleading behaviour when
no match is taken: MSIE presents an empty list to choose from and
Communicator just says you have no client certificates.

> Also note that your wording "There is a provision to just send the
> acceptable issuer names not just as part of the server chain" is
> misleading.  The certificates in the server chain may have nothing to
> do with the CAs the server accepts for clients.  For example, the
> server's certificate might be issued by one of the large commercial
> CAs (Verisign, Thawte, ...), but the only accepted client certs might
> be those issued be the webmaster's own CA (perhaps used in order to
> protect /server-stat and access to the logfiles from the public).
> 

This has to be taken into the context of the original query where the
sender was assuming that the acceptable CA list was just communicated by
including the CAs as part of the server CA chain.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [e-mail]
PGP key: via homepage.