Hello Steve,
Stephen Henson via RT wrote:
> [[EMAIL PROTECTED] - Mon Feb 10 16:53:48 2003]:
>>Stephen Henson via RT wrote:
>>
>>>[[EMAIL PROTECTED] - Fri Feb 7 14:09:28 2003]:
>>>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.
>>
>>I don't see a need for points 3 and 4.
>
> Points 1 to 3 are largely doing what it does now but "properly". However
> it would require some changes to OpenSSL and some new APIs for example
> for new selectable purposes and trust settings for the chain build and
> (possibly) a new cert store.
OK.
I should clarify myself:
It is to do it correctly, but not needed to fix the actual problem.
> However option 4 easy to do and could be argued as being a "bug fix".
OK.
Perhaps something like:
build the chain only with the certs supplied with
SSL_CTX_add_extra_chain_cert()
>>If the CA certs for the server cert are in a seperate list,
>>the content of the cert chain is in control of the user.
>>And if he doesn't want the root cert in the chain, he only
>>has to exclude them in the config file.
>>
>>The actual bug is only because OpenSSL tried to be to smart
>>and included in the list certificates it never was told to include...
>>
>>All I want to have is something like:
>>
>>build the list of server CA certs from the given file
>>(or build by SSL_CTX_add_extra_chain_cert())
>>(in the order I give)
>>and _don't_ include any other certificates...
>>
>
> That's exactly what point 4 would do. You do something like:
>
> SSL_CTX_set_mode(ctx, SSL_MODE_NO_AUTO_CHAIN);
>
> at some stage and it would then just use the supplied certificate(s) in
> SSL_CTX_add_extra_chain_cert().
That are two different things:
1. build the chain with the certs from SSL_CTX_add_extra_chain_cert()
2. verify the chain is correct
(trust settings OK, certs not expired,...)
>>>5. Cache the path after it has been determined.
>>
>>Or build it one time and reuse it...
>
> Which leads to the interesting problem of when to build the chain. If
> its done on first use this will result in configuration errors only
> being apparent after a client connects.
I think it should be done in SSL_CTX_add_extra_chain_cert().
But the return value contains to few
information: only OK or failed.
But the chain has 3 states:
* error in cert chain
* chain certs vaild but incomplete
* chain certs valid and complete
How integrate that in the actual interface ?
since at least mod_ssl test for != 0,
a quick solution would be:
* error in cert chain = 0
* chain certs vaild but incomplete = 1
* chain certs valid and complete = 2
> On the other hand the way that the various certificates and stores are
> presented in arbitrary order, not to mention a new
> SSL_MODE_NO_AUTO_CHAIN flag makes it trickier to determine when its OK
> to build the chain.
As I suggested:
Build it in SSL_CTX_add_extra_chain_cert()
and return a different code for a complete chain...
> Of course the cached chain might also become invalid at some point in
> the future, such as when a certificate expires...
Opens an other question:
There are two validity models for cert chains:
1. A CA cert needs only to be be valid the moment the end entity cert
is issued
2. A CA cert must be valid the complete life time of the end entity
cert.
In both cases you only have to check for expired CA certificates
when you add a certificate to the chain...
Becomes more complicated if you add OCSP...
So you check the complete chain in SSL_CTX_add_extra_chain_cert()
and check the host certificate when it is needed...
But if you want to use the chain until any certificate in it expires,
you can add a time stamp to it (this chain expires at ...)
Bye
Goetz
--
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
