Nginx Configuration HTTPS Server

Http://nginx.org/cn/docs/http/configuring_https_servers.html

Configuring an HTTPS server

The content of the

translation may have been too old. You can view recent updates in the English version.

HTTPS Server Optimization SSL certificate Chain Merging Http/https hosts Name-based HTTPS host SSL certificate with multiple host names Host name indication Compatibility

To configure an HTTPS host, you must open the SSL protocol in the server configuration block and specify the location of the server-side certificate and key file:

server {    listen              443;    server_name         www.example.com;    SSL on                 ;    Ssl_certificate     www.example.com.crt;    Ssl_certificate_key Www.example.com.key;    Ssl_protocols       SSLv3 TLSv1 TLSv1.1 TLSv1.2;    Ssl_ciphers         high:!anull:! MD5;    ...}

The server certificate is public and will be delivered to every client connected to the server. The private key is not public and needs to be stored in a restricted file, and of course, the Nginx master process must have read key permissions. The private key and certificate can be stored in the same file:

    Ssl_certificate     Www.example.com.cert;    Ssl_certificate_key Www.example.com.cert;

In this case, the certificate file also has to set access restrictions. Of course, although the certificate and key are stored in the same file, only the certificate is sent to the client and the key is not delivered.

The Ssl_protocols and Ssl_ciphers directives can be used to force user connections to only introduce SSL/TLS to those strong protocol versions and powerful cryptographic algorithms. Starting with version 1.0.5, Nginx defaults to " ssl_protocols SSLv3 TLSv1 " and " ssl_ciphers HIGH:!aNULL:!MD5 , so it makes sense to configure them explicitly only in previous versions. Starting with the 1.1.13 and 1.0.12 versions, Nginx defaults to " ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2 ".

CBC-mode encryption algorithms are susceptible to some attacks, especially beast attacks (see cve-2011-3389). The Rc4-sha encryption algorithm can be prioritized using the following configuration adjustment:

    Ssl_ciphers rc4:high:!anull:! MD5;    Ssl_prefer_server_ciphers on;

HTTPS Server Optimization

SSL operations consume CPU resources, so in multiprocessor systems, multiple worker processes need to be started, and the number needs to be no less than the number of available CPUs. The SSL operation that consumes the most CPU resources is the SSL handshake, and there are two ways to minimize the number of handshake operations per client: The first is to keep the client long connected, send multiple requests on an SSL connection, and the second is to reuse the SSL session parameters in a concurrent connection or a subsequent connection. This avoids the operation of the SSL handshake. Session caching is used to hold SSL sessions, which are shared between worker processes and can be configured using the Ssl_session_cache directive. A 1M cache can hold approximately 4,000 sessions. The default cache timeout is 5 minutes, and you can use ssl_session_timeout to increase it. The following is an example of a configuration optimization for a 4-core system using a 10M shared session cache:

Worker_processes  4;http {    ssl_session_cache    shared:ssl:10m;    Ssl_session_timeout  10m;    server {        listen              443;        server_name         www.example.com;        Keepalive_timeout   ;        SSL on                 ;        Ssl_certificate     www.example.com.crt;        Ssl_certificate_key Www.example.com.key;        Ssl_protocols       SSLv3 TLSv1 TLSv1.1 TLSv1.2;        Ssl_ciphers         high:!anull:! MD5;        ...

SSL certificate Chain

Some browsers do not accept certificates signed by well-known certification authorities, while others accept them. This is because certificate issuance uses a number of intermediary certification bodies, which are authorized by well-known certification authorities to issue certificates on their behalf, but they are not widely recognized, so some clients do not recognize them. In this case, the certificate Authority provides a package of certificate chains to declare a well-known certification authority and its own relationship, which requires merging this certificate chain package with the server certificate into one file. In this file, the server certificate needs to appear in front of the authentication Party certificate chain:

$ cat Www.example.com.crt bundle.crt > WWW.EXAMPLE.COM.CHAINED.CRT

This file needs to be referenced using the ssl_certificate directive:

server {    listen              443;    server_name         www.example.com;    SSL on                 ;    Ssl_certificate     www.example.com.chained.crt;    Ssl_certificate_key Www.example.com.key;    ...}

If the server certificate and the authentication Party certificate chain are merged in a wrong order, Nginx will not start normally, and the following error message will be displayed:

Ssl_ctx_use_privatekey_file (".../www.example.com.key") failed   (ssl:error:0b080074:x509 certificate routines:    X509_check_private_key:key values mismatch)

Because Nginx first need to use the private key to decrypt the server certificate, but encountered is the certification Party certificate.

Browsers usually keep the intermediary certification bodies that are accredited by the trusted certification authorities, and these browsers later encounter situations where they use these intermediate certification bodies but do not include a certificate chain, because they have already saved the information of these intermediary certification bodies, so they will not report an error. You can use openssl the command-line tool to confirm that the server sent a complete certificate chain:

$ 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 www.GoDaddy.com ("s") of the server certificate (#0) is signed by the issuing authority ("I"), which is the signer of the certificate (#1), and then the issuing authority of the certificate (#1) is the subject of the certificate (#2), and the final certificate (# 2) is a well-known issuing agency Valicert, Inc. issued. Valicert, Inc. 's certificate is embedded in the browser and is automatically recognized by the browser (this is the content of the English poem "In Jack's House").

If you do not join the certification Party certificate chain, only the server certificate (#0) is displayed.

Merging Http/https hosts

If the capabilities of the HTTP and HTTPS virtual hosts are consistent, you can configure a virtual host to handle both HTTP requests and HTTPS requests. The configured method is ssl on to delete the instruction and add the parameters on the *:443 port ssl :

server {    listen              ;    Listen              443 SSL;    server_name         www.example.com;    Ssl_certificate     www.example.com.crt;    Ssl_certificate_key Www.example.com.key;    ...}

prior to version 0.8.21, only default listening ports with parameters added can add ssl parameters:

Listen  443  default SSL;

Name-based HTTPS host

If you configure multiple HTTPS hosts on the same IP, a common problem arises:

server {    listen          443;    server_name     www.example.com;    SSL on             ;    Ssl_certificate www.example.com.crt;    ...} server {    listen          443;    server_name     www.example.org;    SSL on             ;    Ssl_certificate www.example.org.crt;    ...}

Using the above configuration, you will only receive www.example.com a certificate from the default host, regardless of which host the browser requests. This is caused by the behavior of the SSL protocol itself-establishing an SSL connection before sending an HTTP request, so nginx does not know the name of the requested host when establishing an SSL connection, so it only returns the certificate of the default host.

The oldest and most stable solution is to use a different IP address for each HTTPS host:

server {    listen          192.168.1.1:443;    server_name     www.example.com;    SSL on             ;    Ssl_certificate www.example.com.crt;    ...} server {    listen          192.168.1.2:443;    server_name     www.example.org;    SSL on             ;    Ssl_certificate www.example.org.crt;    ...}

SSL certificate with multiple host names

There are other ways to implement multiple HTTPS hosts to share an IP address, but there are deficiencies. One way is to use a certificate that holds multiple names in the "SubjectAltName" field, such as www.example.com and www.example.org . However, the length of the "SubjectAltName" field is limited.

Another way is to use a certificate with a wildcard in the host name, for example *.example.org . This certificate matches www.example.org , but does not match example.org and www.sub.example.org . The two methods can be combined-using certificates of multiple names stored in the "SubjectAltName" field, which can be either exact names or wildcard characters, such as example.org and *.example.org .

It is best to configure the certificate with multiple names and its key file in the HTTP configuration block so that only one copy of the content is saved, and all hosts are configured to inherit from it:

Ssl_certificate      Common.crt;ssl_certificate_key  common.key;server {    listen          443;    server_name     www.example.com;    SSL on             ;    ...} server {    listen          443;    server_name     www.example.org;    SSL on             ;    ...}

Host name indication

A more general scenario for running multiple HTTPS hosts on one IP is the TLS hostname indication extension (sni,rfc6066), which allows the browser and server to pass the requested hostname to the server when the SSL handshake is made, so the server can know which certificate to use to service the connection. But SNI is supported only by limited browsers. Below is a list of the minimum browser version and platform information that supports SNI:

• Opera 8.0;
• MSIE 7.0 (only on Windows Vista operating system and subsequent operating systems);
• Firefox 2.0 and other browsers using the Mozilla platform version 1.8.1;
• Safari 3.2.1 (Windows Edition requires a minimum vista OS);
• Chrome (Windows edition requires a minimum Vista operating system).

only domain names can be passed through SNI, but when the request contains a readable IP address, some browsers transmit the server's IP address as the name of the server. This is a mistake and you should not rely on this.

In order to use SNI in Nginx, it is necessary to support SNI either for the OpenSSL class library used when compiling nginx or for the OpenSSL runtime used when running Nginx. Starting with the 0.9.8f release, OpenSSL joins SNI support with the "--enable-tlsext" configuration option, which is the default option starting with the 0.9.8j version. When Nginx is compiled to support SNI, the following information is displayed when running with the "-V" option:

$ nginx-v ... TLS SNI Support enabled ...

However, when the Nginx support is enabled to be dynamically linked to a OpenSSL library that does not support SNI, Nginx displays the following warning:

Nginx was built with SNI support, however, now it's linkeddynamically to a OpenSSL library which has no tlsext support,t Herefore SNI is not available

Compatibility

• Starting with the 0.8.21 and 0.7.62 versions, the SNI support status information is displayed when you run Nginx with the "-V" option.
• Starting with version 0.7.14, the Listen directive supports ssl parameters.
• Starting with version 0.5.32, SNI is supported.
• Starting with version 0.5.6, SSL session caching is supported and can be shared between worker processes.

• 0.7.65, 0.8.19, and later versions, the default SSL protocol is SSLV3, TLSV1, TLSc1.1, and TLSv1.2 (if the OpenSSL library supports it).
• 0.7.64, 0.8.18, and previous versions, the default SSL protocol is SSLV2, SSLv3, and TLSv1.

• 1.0.5 and later versions, the default SSL cipher algorithm is HIGH:!aNULL:!MD5 .
• 0.7.65, 0.8.20, and later versions, the default SSL cipher algorithm is HIGH:!ADH:!MD5 .
• 0.8.19 version, the default SSL cipher algorithm is ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM .
• 0.7.64, 0.8.18, and previous versions, the default SSL cipher algorithm is ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP .

Author: Igor Sysoev Editor: Brian Mercer Translation: Cfsego

The above describes the Nginx configuration HTTPS server, including the aspects of the content, I hope the PHP tutorial interested in a friend helpful.

