On 23/10/13 18:07, W-Mark Kubacki wrote:
Hi,
As someone about to purchase two certificates please allow me to
weight in an outside perspective:
Thanks!
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 [1] ;-) ).
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 agree.
I would disable OCSP for now in such cases and implement it later.
Why's that?
[1]
http://git.openssl.org/gitweb/?p=openssl.git;a=patch;h=bb65e3f22bc743f2427b6ed4144d654ec7ddaeef
--
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
