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

The fact remains that "ssl_certificate" is singular, and its description is less than clear.
So, thank you for the explanation, because it completes the original description.

Certificate chains are way longer than 2 (leaf + ca) nowadays. CRL checks can encompass 20+ nodes.
It is for this reason, the lenght of the chain, that I still remain of the opinion that "ssl_certificate" ought to
be limited to the leaf's own public certificate. The intermediates ought to be bundled on a separate file.

Labels...

ssl_certificate_key -----> ssl_private_certificate[...cough...]_key
ssl_certificate 1/2 ------> ssl_public_certificate
ssl_certificate 2/2 -------> ssl_public_intermediate_certificates
ssl_trusted_certificate -> ssl_public_ca_certificate

I hate the first two, and definitely prefer the original.
The third could simply be "ssl_intermediates", and the fourth "ssl_ca".
Whatever, I think they will stay as they are anyway.

> security.OCSP.GET.enabled is set to "false" by default

In my FF it set to "false" too, and flipping it does not make any difference,
so my local problem is neither with GET nor with POST.

It turns out that the problem is "security.ssl.enable_ocsp_stapling", which is
"true" by default. If I disable it, then FF loads the web sites. If I re-enable it,
then FF complains again:

> Secure Connection Failed
> An error occurred during a connection to madreacqua.org.
> Invalid OCSP signing certificate in OCSP response.
> (Error code: sec_error_ocsp_invalid_signing_cert)
>
> The page you are trying to view cannot be shown because the authenticity
> of the received data could not be verified.
> Please contact the website owners to inform them of this problem.

If FF is correct, then nginx is returning a bad certificate, and we are back to square one.

Is it the bundle of certificates? No, because I have verified the chain from nginx,
both by hand and automatically with openssl and libressl.

It is GET instead of POST again? No, it is not, because FF "fails" in both cases.