On 17/10/13 23:00, Piotr Sikora wrote:
> Hey,
>
>> I would rather see ssl_certificates to be used this way, something
>> like:
>>
>> ssl_certificate rsa.crt;
>> ssl_certificate_key rsa.key;
>>
>> ssl_certificate ecc.crt;
>> ssl_certificate_key ecc.key;
>
> Yeah, I'm in favor of that syntax as well.
>
>> AFAIR, OpenSSL only able to store one certificate chain per
>> SSL_CTX, which is the root cause of the problem.
>
> That's solved in OpenSSL-1.0.2 (unreleased).

Thanks Piotr. I tried building Nginx with my v2 patch against
OpenSSL_1_0_2, but I didn't see any change in behaviour. i.e. With an
RSA cert and an ECC cert issued by different CAs, Nginx sends the
intermediate certs from both chains in both cases.

Nginx uses SSL_CTX_add_extra_chain_cert(), and I think that might be the
problem. That function's 1_0_2 man page says "Different chains for
different certificates (for example if both RSA and DSA certificates are
specified by the same server) or different SSL structures with the same
parent SSL_CTX cannot be specified using this function. For more
flexibility functions such as SSL_add1_chain_cert() should be used instead."

I'll investigate more next week.

> For now, the one thing we could do is to let OpenSSL build certificate
> chains from the trusted certificates store... In order to do that, all
> we need to do is to load only the first certificate in the file (i.e.
> don't load intermediate certificates) in case there are multiple
> certificates defined. This way, OpenSSL will try to build the
> certificate chain automatically (unfortunately, it will do that on the
> fly for each connection, so it's a noticeable overhead).

Yes, but (assuming "...from the trusted certificates store" would do
syscalls and disk access for every connection) hasn't Maxim already said
that that overhead would be unacceptable?

> Optimized version of that could compare intermediates from all the
> files and only do that in case they differ.

--
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