On 23/10/13 18:07, W-Mark Kubacki wrote:
As someone about to purchase two certificates please allow me to weight in an outside perspective:
On 2013-10-22 12:09 UTC Maxim Dounin wrote:
An unwanted side effect would be that this will allow client certificate authentication to use certs from a server's certificate chain. Probably not something we want to happen.
On 2013-10-22 13:31 UTC Rob Stradling replied:
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.
Just drop the backwards-compatibility and require OpenSSL 1.0.2 or later for that feature, just like a particular version of OpenSSL is needed for TLS-SNI.
Apache httpd can do RSA+DSA+ECC with OpenSSL 1.0.0, and OCSP Stapling works correctly (in recent OpenSSL versions anyway - see  ;-) ).
Why wouldn't Nginx want to offer the same compatibility?
CAs are already starting to sell ECC certs. OpenSSL 1.0.2 isn't even released yet, so most sites will be stuck on <1.0.2 for quite some time.
Most sites don't use TLS client authentication, so they wouldn't be affected by the "unwanted side effect" anyway.
On 2013-10-23 00:25 UTC Maxim Dounin wrote:
Given the number of problems, it might be easier to assume the [certificate-]chains must be the same. […]
• When you are about to get two certificates, most likely RSA+ECC, you go for a ECC-only and a RSA-only chain: The former because clients support ECC anyway, all the way up to the CA. If not, then the latter »classic« RSA-chain would be used. • Additionally, it enables you to purchase from more than one CA — which is good if a visitor with a recent browser doesn't want to trust a CA anymore.
I would disable OCSP for now in such cases and implement it later.