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
