Hello!

On Thu, May 07, 2015 at 11:54:21AM -0400, 173279834462 wrote:

[...]

> problem 1
> -------------
>
> nginx's "ssl_certificate" (note the singular) is truly a bundle of the
> certificate and the intermediate.
> In fact, if we remove the intermediate, we break the chain.
>
> The description for "ssl_certificate" is also misleading.
>
> "Specifies a file with the certificate in the PEM format for the given
> virtual server. If intermediate certificates should be specified in addition
> to a primary certificate, they should be specified in the same file in the
> following order: the primary certificate comes first, then the intermediate
> certificates. A secret key in the PEM format may be placed in the same file.
> "
> http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate
>
> Although the above sentence "If intermediate certificates should be
> specified" suggests that one may omit the intermediate certificate, in
> reality you can only do this if you are the CA. I do not wish to sound
> opinionated here, because I am making an effort to stick to the facts: if we
> remove the intermediate, we do break the chain and the openssl test
> complains loudly.

This depends on how your certificate is issued. If your
certificate is issued directly by root CA certificate, then you don't
need any extra certs here. If there are some intermediate certs,
then you'll have to put them also.

When this directive was introduced, almost all certificates were
issued directly by roots. No in most cases intermediate
certificates are additionally required. Either way, this doesn't
actually change things: think of it as "SSL certificate and
certificate chain" if you want some better mnemonic.

> Therefore, if your own facts correspond to the above, then the solution is
> to edit nginx's source to limit "ssl_certificate" to the leaf's public key
> only, and correct the description accordingly. The intermediate(s) can be
> bundled in a separate file.
>
> It would be easier on the eyes to re-write the keywords as well:
>
> ssl_certificate_key -----> private_certificate
> ssl_certificate 1/2 ------> public_certificate
> ssl_certificate 2/2 -------> public_intermediate_certificates
> ssl_trusted_certificate -> public_ca_certificate
>
> In so doing, the configuration would finally be unambiguous.

Some most obvious issues:

- the "ssl_" prefix, common one for all ngx_http_ssl_module
directives, is lost;

- the term "private certificate" is just wrong, there is no such
thing.

So no, thanks, doesn't looks like an improvement for me.

> problem 2
> --------------
>
> If it is true that FF uses POST to *read*, by default, then this explains
> the original problem with OCSP, and the fact that nginx is well configured
> and openssl and other browsers do work as expected. Google and other search
> engines show that Firefox has been affected by this OCSP problem for a long
> time. Perhaps they could start using GET like everybody else?

Unless you are CA and running your own OCSP server, you shouldn't
care. If you do - you probably already know that not everybody
uses GET for OCSP requests, and most notable exception is OpenSSL
itself. Actually, there are more interoperability problems with
GET OCSP requests than with POST ones, and that's probably why
security.OCSP.GET.enabled is set to "false" by default. Also note
that it's a wrong list to suggest changes to Firefox.

--
Maxim Dounin
http://nginx.org/

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