OCSP stapling: ssl_trusted_certificate directive.

The directive allows to specify additional trusted Certificate Authority
certificates to be used during certificate verification.  In contrast to
ssl_client_certificate DNs of these cerificates aren't sent to a client
during handshake.

Trusted certificates are loaded regardless of the fact whether client
certificates verification is enabled as the same certificates will be
used for OCSP stapling, during construction of an OCSP request and for
verification of an OCSP response.

The same applies to a CRL (which is now always loaded).


git-svn-id: svn://svn.nginx.org/nginx/trunk@4873 73f98a42-aea0-e011-b76d-00259023448c
OCSP stapling: ssl_stapling_file support.

Very basic version without any OCSP responder query code, assuming valid
DER-encoded OCSP response is present in a ssl_stapling_file configured.

Such file might be produced with openssl like this:

openssl ocsp -issuer root.crt -cert domain.crt -respout domain.staple \
             -url http://ocsp.example.com


git-svn-id: svn://svn.nginx.org/nginx/trunk@4874 73f98a42-aea0-e011-b76d-00259023448c
OCSP stapling: the ngx_event_openssl_stapling.c file.

Missed in previous commit.


git-svn-id: svn://svn.nginx.org/nginx/trunk@4875 73f98a42-aea0-e011-b76d-00259023448c
OCSP stapling: loading OCSP responses.

This includes the ssl_stapling_responder directive (defaults to OCSP
responder set in certificate's AIA extension).

OCSP response for a given certificate is requested once we get at least
one connection with certificate_status extension in ClientHello, and
certificate status won't be sent in the connection in question.  This due
to limitations in the OpenSSL API (certificate status callback is blocking).

Note: SSL_CTX_use_certificate_chain_file() was reimplemented as it doesn't
allow to access the certificate loaded via SSL_CTX.


git-svn-id: svn://svn.nginx.org/nginx/trunk@4876 73f98a42-aea0-e011-b76d-00259023448c
OCSP stapling: check Content-Type.

This will result in better error message in case of incorrect response
from OCSP responder:

... OCSP responder sent invalid "Content-Type" header: "text/plain"
    while requesting certificate status, responder: ...

vs.

... d2i_OCSP_RESPONSE() failed (SSL:
    error:0D07209B:asn1 encoding routines:ASN1_get_object:too long
    error:0D068066:asn1 encoding routines:ASN1_CHECK_TLEN:bad object header
    error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error)
    while requesting certificate status, responder: ...


git-svn-id: svn://svn.nginx.org/nginx/trunk@4877 73f98a42-aea0-e011-b76d-00259023448c
OCSP stapling: log error data in ngx_ssl_error().

It's hard to debug OCSP_basic_verify() failures without the actual error
string it records in the error data field.


git-svn-id: svn://svn.nginx.org/nginx/trunk@4878 73f98a42-aea0-e011-b76d-00259023448c
OCSP stapling: OCSP_basic_verify() OCSP_TRUSTOTHER flag now used.

This is expected to simplify configuration in a common case when OCSP
response is signed by a certificate already present in ssl_certificate
chain.  This case won't need any extra trusted certificates.


git-svn-id: svn://svn.nginx.org/nginx/trunk@4879 73f98a42-aea0-e011-b76d-00259023448c
OCSP stapling: ssl_stapling_verify directive.

OCSP response verification is now switched off by default to simplify
configuration, and the ssl_stapling_verify allows to switch it on.

Note that for stapling OCSP response verification isn't something required
as it will be done by a client anyway.  But doing verification on a server
allows to mitigate some attack vectors, most notably stop an attacker from
presenting some specially crafted data to all site clients.


git-svn-id: svn://svn.nginx.org/nginx/trunk@4880 73f98a42-aea0-e011-b76d-00259023448c
OCSP stapling: build fixes.

With the "ssl_stapling_verify" commit build with old OpenSSL libraries
was broken due to incorrect prototype of the ngx_ssl_stapling() function.
One incorrect use of ngx_log_debug() instead of ngx_log_debug2() slipped in
and broke win32 build.


git-svn-id: svn://svn.nginx.org/nginx/trunk@4881 73f98a42-aea0-e011-b76d-00259023448c