On 23/10/13 01:25, Maxim Dounin wrote:
> On Tue, Oct 22, 2013 at 02:31:01PM +0100, Rob Stradling wrote:
<snip>
>> Yes, that's a potentially unwanted side effect. But unfortunately,
>> AFAICT, putting the intermediates into the "trusted certificates
>> store" is the only way to implement this feature with OpenSSL
>> <1.0.2.
>>
>> Could you live with this side effect if the user had to explicitly
>> enable it? Like this...
<snip>
> I think this should be left up to a user. That is, if user want
> us to work this way, he can use the ssl_trusted_certificate directive
> to supply needed certs.

OK.

When multiple certs are configured, OpenSSL <1.0.2 is being used, and
there are 1 or more Intermediate certs in the ssl_certificate files that
will therefore be ignored, I think it would be helpful to log a warning
(to inform the user that those certs have been ignored and would need to
be moved to the ssl_trusted_certificate file).

<snip>
>> OCSP_basic_verify() calls ocsp_find_signer() to locate the
>> certificate that signed the OCSP Response, but this function only
>> looks in the first 2 of those 3 places. (There's a comment "/*
>> Maybe lookup from store if by subject name */", but no associated
>> code).
>
> Err, sorry, I've somehow misread you mail and tought you are
> talking about "issuer certificate not found" errors. The
> OCSP_basic_verify() indeed will likely require additional fixes
> and/or workarounds.

Yep. I've made a start on attempting to change the stapling code to
support multiple certs. (Hopefully I'll be able to complete this!)

>> This is a problem for OCSP Responses that are signed directly by the
>> CA certificate (rather than by a delegated OCSP Response Signing
>> Certificate). It currently works because that CA certificate is
>> almost certainly present in extra_chain_certs. But, to support
>> RSA+DSA+ECC certs signed by different intermediates, we already
>> established that we can't use extra_chain_certs.
>>
>> To workaround this, I think the only option would be to pass to
>> OCSP_basic_verify() a different STACK_OF(X509) that includes all of
>> the extra_chain_certs plus whatever other CA certificates that Nginx
>> can lay its hands on!
>
> Given the number of problems, it might be easier to assume the
> chains must be the same.

I'm not ready to give up yet. :-)

> How it looks from a CA point of view?

We plan to issue RSA certs from an RSA CA, and ECC certs from an ECC CA.

AIUI, TLS <=1.1 requires ECC certs to be issued by an ECC CA, and RSA
certs to be issued by an RSA CA - see RFC4492 section 2. Only TLS 1.2
allows ECC certs to be issued by an RSA CA (and vice versa).

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel