Page Discussion History


Revision as of 19:47, 2 May 2012 by Admin (Talk | contribs)



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_server 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:


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_server ssl;
  server_name      secure.nginx.org;
server {
  listen           80;
  listen           443;
  server_name      images.nginx.org;



Syntax: ssl on | off
Default: off
Context: http

Enables HTTPS for a server. (Note that since nginx version 0.7.14, the standard way to enable SSL is through the listen directive.)


Syntax: ssl_certificate file
Context: http

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.


Syntax: ssl_certificate_key file
Context: http

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.


Syntax: ssl_ciphers ciphers
Default: HIGH:!aNULL:!MD5
Context: http

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:


Since nginx version 1.0.5, the default ciphers are:

ssl_ciphers  HIGH:!aNULL:!MD5;

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

openssl ciphers


Syntax: ssl_client_certificate file
Context: http

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


Syntax: ssl_crl file
Context: http
Appeared in: 0.8.7

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.


Syntax: ssl_dhparam file
Context: http
Appeared in: 0.7.2

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.


Syntax: ssl_prefer_server_ciphers on | off
Default: off
Context: http

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


Syntax: ssl_protocols [ SSLv2 ] [ SSLv3 ] [ TLSv1 ] [ TLSv1.1 ] [ TLSv1.2 ]
Default: SSLv3 TLSv1 TLSv1.1 TLSv1.2
Context: http

This directive enables the protocol versions specified.


Syntax: ssl_verify_client on | off | optional | optional_no_ca
Default: off
Context: http

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)


Syntax: ssl_verify_depth number
Default: 1
Context: http

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


Syntax: ssl_session_cache off | none | [ builtin [: size ]] [ shared : name : size ]
Default: none
Context: http

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.


Syntax: ssl_session_timeout time
Default: 5m
Context: http

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.


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.