Nginx Http Ssl Module

Nginx Http Ssl Module:

This module enables HTTPS support.

It supports checking client certificates with two limitations:

• it’s not possible to assign a Certificate Revocation List for Nginx versions below 0.8.7.
• if you have a chain of certificates — by having intermediate certificates between the server certificate and the CA root certificate — they’re not specified separately like you would do for Apache. Instead you’ll need to concatenate all the certificates, starting with the server certificate, and going deeper in the chain running through all the intermediate certificates. This can be done with “cat chain.crt >> mysite.com.crt” on the command line. Once this is done there’s no further use for all the intermediate certificates in what Nginx is concerned. You’ll indicate in the Nginx configuration the file with all the (concatenated) certificates.

By default the module is not built, it is necessary to state it explicitly: give the –with-http_ssl_module parameter to ./configure. Building this module requires the OpenSSL library and respective include files; quite often the library and include files live in separate packages in your platform, the later being named like libssl-dev or similar.

The following is an example configuration, to reduce the CPU load it is recommended to run one worker process only and to enable keep-alive connections:

worker_processes 1;
http {
  server {
    listen               443;
    ssl                  on;
    ssl_certificate      /usr/local/nginx/conf/cert.pem;
    ssl_certificate_key  /usr/local/nginx/conf/cert.key;
    keepalive_timeout    70;
  }
}

When using a chain of certificates, just append the extra certificates to your .crt file (cert.pem in the example). The server certificate needs to be the first on the file, otherwise you’ll get a mismatch between private and public keys.

Since Nginx version 0.7.14 the preferred way of enabling SSL is by using the `ssl` parameter of the `listen` directive:

server {
  listen 443 default ssl;
  ssl_certificate      /usr/local/nginx/conf/cert.pem;
  ssl_certificate_key  /usr/local/nginx/conf/cert.key;
  ...
}

Generate Certificates

To generate private (dummy) certificates you can perform the following list of openssl commands.

First change directory to where you want to create the certificate and private key, for example:

$ cd /usr/local/nginx/conf

Now create the server private key, you’ll be asked for a passphrase:

$ openssl genrsa -des3 -out server.key 1024

Create the Certificate Signing Request (CSR):

$ openssl req -new -key server.key -out server.csr

Remove the necessity of entering a passphrase for starting up nginx with SSL using the above private key:

$ cp server.key server.key.org
$ openssl rsa -in server.key.org -out server.key

Finally sign the certificate using the above private key and CSR:

$ openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Update Nginx configuration by including the newly signed certificate and private key:

server {
    server_name YOUR_DOMAINNAME_HERE;
    listen 443;
    ssl on;
    ssl_certificate /usr/local/nginx/conf/server.crt;
    ssl_certificate_key /usr/local/nginx/conf/server.key;
}

Restart Nginx.

Now we’re ready to access the above host using:

https://YOUR_DOMAINNAME_HERE

Using Wildcard certificates with multiple servers

In some instances you may wish to provide a number of secure subdomains amongst unsecured ones, and possibly share resources across both HTTP and HTTPS subdomains. To do this one would require a wildcard subdomain, for example *.nginx.org. An example configuration follows which shows how to configure a standard www subdomain, a secured subdomain, and share images across both subdomains using a third.

When using a configuration like this it’s more efficient memory wise to place the certificate file containing the certificate(s) for all domain names and the corresponding private key file directives in a http context, such that it’s inherited by all active servers/virtual hosts:

ssl_certificate      common.crt;
ssl_certificate_key  common.key;

server {
  listen           80;
  server_name      www.nginx.org;
  ...
}

server {
  listen           443 default ssl;
  server_name      secure.nginx.org;
  ...
}

server {
  listen           80;
  listen           443;
  server_name      images.nginx.org;
  ...
}

Directives

ssl

syntax: ssl [on|off]

default: ssl off

context: main, server

Enables HTTPS for a server.

ssl_certificate

syntax: ssl_certificate file

default: ssl_certificate cert.pem

context: main, server

This directive specifies the file containing the certificate, in PEM format, for this virtual host. This file can contain also other certificates and the server private key. Since version 0.6.7 the file path is relative to the directory where nginx main configuration file, nginx.conf, resides.

ssl_certificate_key

syntax: ssl_certificate_key file

default: ssl_certificate_key cert.pem

context: main, server

This directive specifies the file containing the private key, in PEM format, for this virtual host. Since version 0.6.7 the file path is relative to the directory where nginx main configuration file, nginx.conf, resides.

ssl_client_certificate

syntax: ssl_client_certificate file

default: none

context: main, server

This directive specifies the file containing the CA (root) certificate, in PEM format, that is used for validating client certificates.

ssl_dhparam

syntax: ssl_dhparam file

default: none

context: main, server

This directive specifies a file containing Diffie-Hellman key agreement protocol cryptographic parameters, in PEM format, utilized for exchanging session keys between server and client.

ssl_ciphers

syntax: ssl_ciphers openssl_cipherlist_spec

default: ssl_ciphers ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP

context: main, server

This directive describes the list of cipher suites the server supports for establishing a secure connection. Cipher suites are specified in the OpenSSL cipherlist format, for example:

ssl_ciphers  ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;

The complete cipherlist supported by the currently installed version of OpenSSL in your platform can be obtained by issuing the command:

openssl ciphers

ssl_crl

syntax: ssl_crl file

default: none

context: http, server

This directive, introduced in Nginx version 0.8.7, specifies the filename of a Certificate Revocation List, in PEM format, which is used to check the revocation status of certificates.

ssl_prefer_server_ciphers

syntax: ssl_prefer_server_ciphers [on|off]

default: ssl_prefer_server_ciphers off

context: main, server

The server requires that the cipher suite list for protocols SSLv3 and TLSv1 are to be preferred over the client supported cipher suite list.

ssl_protocols

syntax: ssl_protocols [SSLv2] [SSLv3] [TLSv1]

default: ssl_protocols SSLv2 SSLv3 TLSv1

context: main, server

This directive enables the protocol versions specified.

ssl_verify_client

syntax: ssl_verify_client on|off|optional

default: ssl_verify_client off

context: main, server

This directive enables the verification of the client identity. Parameter ‘optional’ checks the client identity using its certificate in case it was made available to the server. (Was ‘ask’ before 0.8.7 and 0.7.63)

ssl_verify_depth

syntax: ssl_verify_depth number

default: ssl_verify_depth 1

context: main, server

This directive sets how deep the server should go in the client provided certificate chain in order to verify the client identity.

ssl_session_cache

syntax: ssl_session_cache off|none|builtin:size and/or shared:name:size

default: ssl_session_cache off

context: main, server

The directive sets the types and sizes of caches to store the SSL sessions.
The cache types are:

• off — Hard off: nginx says explicitly to a client that sessions can not reused.
• none — Soft off: nginx says to a client that session can be resued, but nginx actually never reuses them. This is workaround for some mail clients as ssl_session_cache may be used in mail proxy as well as in HTTP server.
• builtin — the OpenSSL builtin cache, is used inside one worker process only. The cache size is assigned in the number of the sessions. Note: there appears to be a memory fragmentation issue using this method, please take that into consideration when using this. See “References” below.
• shared — the cache is shared between all worker processes. The size of the cache is assigned in bytes: 1 MB cache can contain roughly 4000 sessions. Each shared cache must be given an arbitrary name. A shared cache with a given name can be used in several virtual hosts.

It’s possible to use both types of cache — builtin and shared — simultaneously, for example:

  ssl_session_cache  builtin:1000  shared:SSL:10m;

Bear in mind however, that using only shared cache, i.e., without builtin, should be more effective.

For Nginx versions below 0.8.34 this directive shouldn’t be set to ‘none’ or ‘off’ if ssl_verify_client is set to ‘on’ or ‘optional’.

• Note that for session resumption to work you’ll need to have, at least, the server configured as default for the SSL socket. Like this:

listen [::]:443 ssl default_server;

This is so because session resumption happens before any TLS extensions are enabled, namely Server Name Identification (SNI). The ClientHello message requests a session ID from a given IP address (server). For that to work the default server setting is required.

A preferred approach is to move the ssl_session_cache directive to the http context. The (minor) downside is that all configured virtual hosts get the same SSL cache settings.

ssl_session_timeout

syntax: ssl_session_timeout time

default: ssl_session_timeout 5m

context: main, server

This directive defines the maximum time during which the client can re-use the previously negotiated cryptographic parameters of the secure session that is stored in the SSL cache.

ssl_engine

syntax: ssl_engine

This allows specifying the OpenSSL engine to use, like PadLock for example. It requires a recent version of OpenSSL. To verify if the OpenSSL version installed in your platform supports this, issue the command:

openssl engine

On a Debian testing with OpenSSL version 0.9.8o from 01 Jun 2010 it returns:

$ openssl engine
(padlock) VIA PadLock (no-RNG, no-ACE)
(dynamic) Dynamic engine loading support

Built-in variables

Module ngx_http_ssl_module supports the following built-in variables:

• $ssl_cipher returns the cipher suite being used for the currently established SSL/TLS connection
• $ssl_client_serial returns the serial number of the client certificate for the currently established SSL/TLS connection — if applicable, i.e., if client authentication is activated in the connection
• $ssl_client_s_dn returns the subject Distinguished Name (DN) of the client certificate for the currently established SSL/TLS connection — if applicable, i.e., if client authentication is activated in the connection
• $ssl_client_i_dn returns the issuer DN of the client certificate for the currently established SSL/TLS connection — if applicable, i.e., if client authentication is activated in the connection
• $ssl_protocol returns the protocol of the currently established SSL/TLS connection — depending on the configuration and client available options it’s one of SSLv2, SSLv3 or TLSv1
• $ssl_session_id the Session ID of the established secure connection — requires Nginx version greater or equal to 0.8.20
• $ssl_client_cert
• $ssl_client_raw_cert
• $ssl_client_verify takes the value “SUCCESS” when the client certificate is successfully verified

Nonstandard error codes

This module supports several nonstandard error codes which can be used for debugging with the aid of directive error_page:

• 495 – error checking client certificate
• 496 – client did not grant the required certificate
• 497 – normal request was sent to HTTPS

Debugging is done after the request is completely “disassembled” and it’s components are accessible via variables such as $request_uri, $uri, $arg and more.