[[EMAIL PROTECTED] - Fri Feb  7 14:09:28 2003]:

> 
> According to RFC 2246 a server can omitt the root certificate:
> [...]
>     certificate_list
>         This is a sequence (chain) of X.509v3 certificates. The sender's
>         certificate must come first in the list. Each following
>         certificate must directly certify the one preceding it. Because
>         certificate validation requires that root keys be distributed
>         independently, the self-signed certificate which specifies the
>         root certificate authority may optionally be omitted from the
>         chain, under the assumption that the remote end must already
>         possess it in order to validate it in any case.
> [...]
> 
> But OpenSSL tries to complete the server CA list with the certificates
> set in the client CA list.
> 
> This can result in an invalid server CA list if the client CA list
> contains a CA cert with a DN that matches the issuer DN in the server
> cert or the root CA cert of the server CA list.
> 
> So it is not possible for the servwe to accept client certs issued
> by the own root CA and prevent this root from being sent to the client 
> as own root.
> 
> 

Indeed, it uses a primitive path building algorithm in
ssl3_output_cert_chain() which relies on the first certificate it finds
whose subject matches the issuer name of the current certificate to be
the next in the chain and halts when it finds one with issuer and
subject names being equivalent.

IIRC this is very old code and has been about since the early SSLeay days.

There are a number of problems with it. 

1. It takes no notice of extensions, purpose or trust settings.  

2. It does no additional validation such as checking expiry dates on
certificates, so the server (or client) can happily output an expired
chain and leave the peer (e.g. users with web browsers) to report the
problem.

3. There is no indication that the operation has failed. In some cases
where a server chain contains three or more certificates failure will
mean it wont output the intermediate CA. The peer may be unable to form
the complete chain: depending on whether it has the intermediate CA in
its database.

4. If there are extra certificates they are output as well as those
found by this method.

5. It is inefficient: the code gets called every time a chain is output
including potentially expensive X509_LOOKUP operations.


It really needs replacing with something less horrible. For example it
might:

1. Build the chain using the normal certificate verify code including
the usual checks on validity and using appropriate purpose and trust.

2. Give a (fatal?) error if the verification fails.

3. Include a flag to exclude the root CA from outputted chain.

4. Include an flag to disable the automatic chain building altogether
and rely on the chain being correctly present in the extra certs of the
context.

5. Cache the path after it has been determined.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to