nginx Configuring HTTPS servers

cencenhai

　　HTTPS server optimization

SSL certifcate chains

A single HTTP/HTTPS server

Name-based HTTPS servers

A SSL certificate with several names

Server Name Indication

Compatibility
　　
To configure an HTTPS server you must enable the SSL protocol
in the server block, and specify the locations of the server certificate
and private key files:

server {
listen               443;
server_name          www.nginx.com;
ssl                  on;
ssl_certificate      www.nginx.com.crt;
ssl_certificate_key  www.nginx.com.key;
ssl_protocols        SSLv3 TLSv1;
ssl_ciphers          HIGH:!ADH:!MD5;
...
}

The server certificate is a public entity.
It is sent to every client that connects to the server.
The private key is a secure entity and should be stored in a file with
restricted access, however, it must be readable by nginx’s master process.
The private key may alternately be stored in the same file as the certificate:

    ssl_certificate      www.nginx.com.cert;
ssl_certificate_key  www.nginx.com.cert;

in which case the file access rights should also be restricted.
Although the certificate and the key are stored in one file,
only the certificate is sent to a client.

　　
The directives “ssl_protocols” and
“ssl_ciphers” may be used to limit connections
to strong SSL protocol versions and ciphers.
Since version 0.8.20, nginx uses “ssl_protocols SSLv3 TLSv1”
and “ssl_ciphers HIGH:!ADH:!MD5” by default,
so they should only be set for earlier nginx versions.

　　


HTTPS server optimization
　　
SSL operations consume extra CPU resources.
On multi-processor systems you should run several worker processes:
no less than the number of available CPU cores.
The most CPU-intensive operation is the SSL handshake.
There are two ways to minimize the number of these operations per client:
the first is by enabling keepalive connections to send several
requests via one connection and the second is to reuse SSL session
parameters to avoid SSL handshakes for parallel and subsequent connections.
The sessions are stored in an SSL session cache shared between workers
and configured by an “ssl_session_cache” directive.
One megabyte of the cache contains about 4000 sessions.
The default cache timeout is 5 minutes. It can be increased by using
the “ssl_session_timeout” directive.
Here is a sample configuration optimized for a quad core system
with 10M shared session cache:

worker_processes  4
;
http {
ssl_session_cache    shared:SSL:10m
;
ssl_session_timeout  10m
;
server {
listen               443;
server_name          www.nginx.com;
keepalive            70
;
ssl                  on;
ssl_certificate      www.nginx.com.crt;
ssl_certificate_key  www.nginx.com.key;
ssl_protocols        SSLv3 TLSv1;
ssl_ciphers          HIGH:!ADH:!MD5;
...

 
　　


SSL certifcate chains
　　
Some browsers may complain about a certificate signed by a well-known
certificate authority, while other browsers may accept the certificate
without issues.
This occurs because the issuing authority has signed the server certificate
using an intermediate certificate that is not present in the certificate
base of well-known trusted certificate authorities which is distributed
with a particular browser.
In this case the authority provides a bundle of chained certificates
which should be concatenated to the signed server certificate.
The server certificate must appear before the chained certificates
in the combined file:

$ cat www.nginx.com.crt bundle.crt > www.nginx.com.chained.crt

The resulting file should be used in the “ssl_certificate”
directive:

server {
listen               443;
server_name          www.nginx.com;
ssl                  on;
ssl_certificate      www.nginx.com.chained.crt;
ssl_certificate_key  www.nginx.com.key;
...
}

If the server certificate and the bundle have been concatenated in the wrong
order, nginx will fail to start and will display the error message:

SSL_CTX_use_PrivateKey_file(" ... /www.nginx.com.key") failed
(SSL: error:0B080074:x509 certificate routines:
X509_check_private_key:key values mismatch)

because nginx has tried to use the private key with the bundle’s
first certificate instead of the server certificate.

　　
Browsers usually store intermediate certificates which they receive
and which are signed by trusted authorities, so actively used browsers
may already have the required intermediate certificates and
may not complain about a certificate sent without a chained bundle.
To ensure the server sends the complete certificate chain,
you may use the “openssl
” command line utility, for example:

$ openssl s_client -connect www.godaddy.com:443
...
Certificate chain
0 s:/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US
/1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc
/OU=MIS Department/CN=www.GoDaddy.com
/serialNumber=0796928-7/2.5.4.15=V1.0, Clause 5.(b)
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
/OU=http://certificates.godaddy.com/repository
/CN=Go Daddy Secure Certification Authority
/serialNumber=07969287
1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
/OU=http://certificates.godaddy.com/repository
/CN=Go Daddy Secure Certification Authority
/serialNumber=07969287
i:/C=US/O=The Go Daddy Group, Inc.
/OU=Go Daddy Class 2 Certification Authority
2 s:/C=US/O=The Go Daddy Group, Inc.
/OU=Go Daddy Class 2 Certification Authority
i:/L=ValiCert Validation Network/O=ValiCert, Inc.
/OU=ValiCert Class 2 Policy Validation Authority
/CN=http://www.valicert.com//emailAddress=info@valicert.com
...

In this example the subject (“s
”) of the
www.GoDaddy.com
server certificate #0 is signed by an issuer
(“i
”) which itself is the subject of the certificate #1,
which is signed by an issuer which itself is the subject of the certificate #2,
which signed by the well-known issuer ValiCert, Inc.
whose certificate is stored in the browsers’ built-in
certificate base (that lay in the house that Jack built).

　　
If you have not added the certificates bundle, you will see only your server
certificate #0.

　　


A single HTTP/HTTPS server
　　
It is good practice to configure separate servers for HTTP and HTTPS
protocols from the very start. Although their functionalities currently
seem equal, this may change significantly in the future
and using a consolidated server may become problematic.
However, if HTTP and HTTPS servers are equal,
and you prefer not to think about the future,
you may configure a single server that handles both HTTP and HTTPS requests
by deleting the directive “ssl on”
and adding the “ssl” parameter for *:443 port:

server {
listen               80;
listen               443  ssl;
server_name          www.nginx.com;
ssl_certificate      www.nginx.com.crt;
ssl_certificate_key  www.nginx.com.key;
...
}

 

Prior to 0.8.21, nginx only allows the “ssl” parameter
to be set on listen sockets with the “default” parameter:

listen  443  default  ssl;

 
　　


Name-based HTTPS servers
　　
A common issue arises when configuring two or more HTTPS servers
listening on a single IP address:

server {
listen           443;
server_name      www.nginx.com;
ssl              on;
ssl_certificate  www.nginx.com.crt;
...
}
server {
listen           443;
server_name      www.nginx.org;
ssl              on;
ssl_certificate  www.nginx.org.crt;
...
}

With this configuration a browser receives the certificate of the default
server, i.e., www.nginx.com
regardless of the requested server name.
This is caused by SSL protocol behaviour. The SSL connection is established
before the browser sends an HTTP request and nginx does not know
the name of the requested server. Therefore, it may only offer the certificate
of the default server.

　　
The oldest and most robust method to resolve the issue
is to assign a separate IP address for every HTTPS server:

server {
listen           192.168.1.1:443;
server_name      www.nginx.com;
ssl              on;
ssl_certificate  www.nginx.com.crt;
...
}
server {
listen           192.168.1.2:443;
server_name      www.nginx.org;
ssl              on;
ssl_certificate  www.nginx.org.crt;
...
}

 
　　


A SSL certificate with several names
　　
There are other ways to share a single IP address between several
HTTPS servers, however, all of them have drawbacks.
One way is to use a certificate with several names in
the SubjectAltName certificate field, for example, www.nginx.com
and www.nginx.org
.
However, the SubjectAltName field length is limited.

　　
Another way is to use a certificate with a wildcard name, for example,
*.nginx.org
. This certificate matches
www.nginx.org
, but does not match nginx.org
and www.sub.nginx.org
. These two methods can also be combined.
A certificate may contain exact and wildcard names in the SubjectAltName field,
for example, nginx.org
and *.nginx.org
.

　　
It is better to place a certificate file with several names and
its private key file at the http
level of configuration
to inherit their single memory copy in all servers:

ssl_certificate      common.crt;
ssl_certificate_key  common.key;
server {
listen           443;
server_name      www.nginx.com;
ssl              on;
...
}
server {
listen           443;
server_name      www.nginx.org;
ssl              on;
...
}

 
　　


Server Name Indication
　　
A more generic solution for running several HTTPS servers on a single
IP address is
TLSv1.1
Server Name Indication extension
(SNI, RFC3546),
which allows a browser to pass a requested server name during the SSL handshake
and, therefore, the server will know which certificate it should use
for the connection.
However, SNI has limited browser support.
Currently it is supported starting with the following browsers versions:

• 
  Opera 8.0;
  
• 
  MSIE 7.0 (but only on Windows Vista or higher);
  
• 
  Firefox 2.0 and other browsers using Mozilla Platform rv:1.8.1;
  
• 
  Safari 3.2.1 (Windows version supports SNI on Vista or higher);
  
• 
  and Chrome (Windows version supports SNI on Vista or higher, too).
  

　　
In order to use SNI in nginx, it must be supported in both the
OpenSSL libraries with which the nginx binary has been built as well as
the libraries to which it is being dynamically linked at run time.
OpenSSL supports SNI since 0.9.8f version if it was built with config option
“--enable-tlsext”.
Since OpenSSL 0.8.9j this option is enabled by default.
If nginx was built with SNI support, then nginx will show this
when run with the “-V” switch:

$ nginx -V
...
TLS SNI support enabled
...

However, if the SNI-enabled nginx is linked dynamically to
an OpenSSL library without SNI support, nginx displays the warning:

nginx was built with SNI support, however, now it is linked
dynamically to an OpenSSL library which has no tlsext support,
therefore SNI is not available

 
　　


Compatibility

• 
  The SNI support status has been shown by the “-V” switch
  since 0.8.21 and 0.7.62.
  
• 
  The “ssl” parameter of the “listen”
  directive has been supported since 0.7.14.
  
• 
  SNI has been supported since 0.5.32.
  
• 
  The shared SSL session cache has been supported since 0.5.6.
  

• 
  Version 0.8.19 and later: the default SSL protocols are SSLv3 and TLSv1.
  
• 
  Version 0.8.18 and earlier: the default SSL protocols are SSLv2,
  SSLv3, and TLSv1.
  

• 
  Version 0.8.20 and later: the default SSL ciphers are
  “HIGH:!ADH:!MD5”.
  
• 
  Version 0.8.19: the default SSL ciphers are
  “ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM”.
  
• 
  Version 0.8.18 and earlier: the default SSL ciphers are
  
  “ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP”.
  

　　written by Igor Sysoev

edited by Brian Mercer