Shulou(Shulou.com)06/01 Report--

Configure the HTTPS server

To configure the 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 is passed to every client that connects to the server. The private key is not public and needs to be stored in a file with limited access. Of course, the nginx main process must have permission to read the key. 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 will be sent to the client, and the key will not be sent.

Ssl_protocols and ssl_ciphers instructions can be used to force users to connect only to those strong protocol versions and powerful encryption algorithms of SSL/TLS. Starting with version 1.0.5, nginx defaults to "ssl_protocols SSLv3 TLSv1" and "ssl_ciphers Higgl Higger", so it only makes sense to explicitly configure them in previous versions. Starting with versions 1.1.13 and 1.0.12, nginx uses "ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2" by default.

Encryption algorithms in CBC mode are vulnerable to some attacks, especially BEAST attacks (see CVE-2011-3389). The RC4-SHA encryption algorithm can be adjusted to give priority to the following configuration:

Ssl_ciphers RC4:HIGH:!aNULL:!MD5

Ssl_prefer_server_ciphers on

HTTPS server optimization

SSL operations consume CPU resources, so in a multiprocessor system, you need to start multiple worker processes, and the number of CPU is not less than the number available. The SSL operation that consumes the most CPU resources is the SSL handshake. There are two ways to minimize the number of handshakes per client: the first is to maintain a long connection on the client, sending multiple requests on a SSL connection, and the second is to reuse SSL session parameters in concurrent or subsequent connections, which avoids the SSL handshake. Session caches are used to hold SSL sessions, which are shared between worker processes and can be configured using the ssl_session_cache directive. The 1m cache can hold approximately 4000 sessions. The default cache timeout is 5 minutes, which can be increased using ssl_session_timeout. The following is an example of 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 70

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 some intermediate certification bodies are used to issue certificates, which are authorized by well-known certificate certification bodies 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 the certificate chain, which is used to declare the relationship between the well-known certification authority and itself, and the certificate chain package needs to be merged with the server certificate into one file. In this file, the server certificate needs to appear at the front of the authenticator 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 authenticator certificate chain are merged in the wrong order, nginx will not start properly 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 needs to decrypt the server certificate with the private key, but what it encounters is the certificate of the authenticator.

Browsers usually save intermediate certification bodies certified by trusted certification bodies, so when these browsers encounter the use of these intermediate certification bodies but do not include certificate chains in the future, because the information of these intermediate certification bodies has been saved, they will not report an error. You can use the openssl 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 signer ("s") of www.GoDaddy.com 's server certificate (# 0) is signed by the issuing authority ("I"), which is the signer of the certificate (# 1), then the issuer of the certificate (# 1) is the signer of the certificate (# 2), and the final certificate (# 2) is issued by the well-known issuing authority ValiCert, Inc. ValiCert, Inc's certificate is embedded in the browser and is automatically recognized by the browser (this passage is similar to the English poem "in the House built by Jack").

If you do not join the authenticator certificate chain, only the server certificate (# 0) will be displayed.

Merge HTTP/HTTPS hosts

If the functions of the HTTP and HTTPS virtual hosts are the same, you can configure a virtual host to handle both HTTP and HTTPS requests. The way to configure it is to delete the instruction of ssl on and add the parameter ssl in port *: 443:

Server {

Listen 80

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 listening ports with the default parameter added could add the ssl parameter:

Listen 443 default ssl

Name-based HTTPS host

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

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

...

}

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

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

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 hostnames

There are other ways to enable multiple HTTPS hosts to share an IP address, but they all have shortcomings. One way to do this is to use certificates with 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 wildcards in the hostname, such as * .example.org. This certificate matches www.example.org, but not example.org and www.sub.example.org. These two methods can be combined-- using certificates with multiple names stored in the "SubjectAltName" field, which can be either exact names or wildcards, such as example.org and * .example.org.

It is best to configure a certificate with multiple names and its key file in the http configuration block so that only one copy of the content can be saved, from which all host configurations are inherited:

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

...

}

Hostname indication

A more common solution for running multiple HTTPS hosts on an IP is the TLS hostname indication extension (SNI,RFC6066), which allows the browser and the server to pass the requested hostname to the server when making an SSL handshake, so the server can know which certificate to use to serve the connection. But SNI is only supported by limited browsers. The following lists the minimum version and platform information of browsers that support SNI:

Opera 8.0

MSIE 7. 0 (only on Windows Vista and subsequent operating systems)

Firefox 2.0 and other browsers that use version 1.8.1 of the Mozilla platform

Safari 3.2.1 (Windows version requires a minimum Vista operating system)

Chrome (the Windows version 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 pass the server's IP address as the server's name. This is a mistake and we should not rely on it.

In order to use SNI in nginx, both the OpenSSL class library used when compiling nginx and the OpenSSL runtime used when running nginx must support SNI. Starting with version 0.9.8f, OpenSSL has added SNI support through the "- enable-tlsext" configuration option, which has become the default option since version 0.9.8j. When nginx is compiled to support SNI, the following message is displayed when running with the "- V" option:

$nginx-V

...

TLS SNI support enabled

...

However, when nginx that is enabled for SNI support is dynamically linked to an OpenSSL library that does not support SNI, nginx displays the following 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

Starting with versions 0.8.21 and 0.7.62, SNI support status information is displayed when you run nginx with the "- V" option.

Starting with version 0.7.14, the listen directive supports the ssl parameter.

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, the default SSL protocols are SSLv3, TLSv1, TLSc1.1, and TLSv1.2 (if the OpenSSL library supports it).

0.7.64,0.8.18 and prior, the default SSL protocols are SSLv2, SSLv3, and TLSv1.

In version 1.0.5 and later, the default SSL cryptographic algorithm is HIGHaveNull _ Vol _ MD5.

In versions 0.7.65,0.8.20 and later, the default SSL cryptographic algorithm is high-level "ADH-R" MD5.

In version 0.8.19, the default SSL cryptographic algorithm is ALLGRON ADH RC4 RSADA HIGHRAR medium.

In 0.7.64,0.8.18 and previous versions, the default SSL cryptographic algorithm is all _ LV _ RC4 _ RSAV _ exp.

Global trusted CA institutions

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.