Chapter 5[ 91 ]The following is an example configuration for enabling HTTPS connections to
server {listen 443 default ssl;server_name http://www.example.com;ssl_prefer_server_ciphers on;ssl_protocols TLSv1 SSLv3;ssl_ciphers RC4:HIGH:!aNULL:!MD5:@STRENGTH;ssl_session_cache shared:WEB:10m;ssl_certificate /usr/local/etc/nginx/www.example.com.crt;ssl_certificate_key /usr/local/etc/nginx/www.example.com.key;location / {proxy_set_header X-FORWARDED-PROTO https;proxy_pass http://upstream;}}In the preceding example, we first activate the ssl module by using the ssl
parameter to the listen directive. Then, we specify that we wish the server's ciphers
to be chosen over the client's list, as we can configure the server to use the ciphers
that have proven to be most secure. This prevents clients from negotiating a cipher
that has been deprecated. The ssl_session_cache directive is set to shared so that
all worker processes can benefit from the expensive SSL negotiation that has already
been done once per client. Multiple virtual servers can use the same sslsession
cache directive if they are all configured with the same name, or if this directive is
specified in the http context. The second and third parts of the value are the name of
the cache and its size, respectively. Then it is just a matter of specifying the certificate
and key for this host. Note that the permissions of this key file should be set such that
only the master process may read it. We set the header X-FORWARDED-PROTO to the
value https so that the application running on the upstream server can recognize
the fact that the original request used HTTPS.