[Linux] PHP programmers play with Linux series-HTTPS in Nginx,-nginxhttps

[Linux] PHP programmers play with Linux series-HTTPS in Nginx,-nginxhttps

1. PHP programmers turn to the Linux series-how to install and use CentOS

2. PHP programmers play with Linux series-lnmp Environment Construction

3. PHP programmers play with the Linux series-build an FTP code Development Environment

4. PHP programmers turn to the Linux series-back up and restore MySQL

5. PHP programmers turn to the Linux series-automatic backup and SVN

6. PHP programmers go to Linux-install nginx on Linux and Windows

7. PHP programmers play with Linux series-nginx beginner Guide

 

Create an HTTPS Server

 

In the nginx. conf configuration file, use the listen command in the server block to specify the ssl parameter and set the path of the server certificate and private key file.

server {    listen              443 ssl;    server_name         www.example.com;    ssl_certificate     www.example.com.crt;    ssl_certificate_key www.example.com.key;    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;    ssl_ciphers         HIGH:!aNULL:!MD5;    ...}

A server certificate is a public entity that is sent to each connected client. A private key is a security entity and should be stored in a file with limited permissions. however, the nginx master process must be able to read the private key file. the private key can also be stored in a file with the certificate.

ssl_certificate www.example.com.cert;ssl_certificate_key www.example.com.cert;

In this example, the file access permission should be restricted. Although the certificate and private key are in the same file, only the certificate will be sent to the client.

The ssl_protocols and ssl_ciphers commands can be used to restrict connections. They only contain the TLS and SSL/TLS passwords of higher versions.

Starting from nginx 1.0.5, nginx uses ssl_protocols SSLv3 TLSv1 and ssl_ciphers HIGH:! by default :! ANULL :! MD5. from nginx 1.1.13 and 1.0.12 versions, it is updated to ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2 by default.

 

A single HTTP and HTTPS service

You can configure a service to support both HTTP and HTTPS requests. Use the listen command in the VM, one with the ssl parameter and the other without the parameter.

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

In nginx 0.7.13 and earlier versions, SSL cannot be separately configured to listen to sockets. you can only enable ssl for all servers using the SSL command to support both HTTP and HTTPS. to solve this problem, an ssl parameter is added to the listen command. therefore, in versions 0.7.14 and later, ssl commands cannot be reused.

 

Name-based HTTPS service

A common problem occurs, that is, when one IP address is configured to listen to two or more HTTPS services.

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

With this configuration, the browser can only receive the default certificate. In this example, the certificate is www.example.com. this is caused by the SSL protocol. the SSL connection is established before the browser sends an HTTP request. Therefore, nginx does not know the Request Name. therefore, it can only provide certificates for default services.

The best way to solve this problem is to assign different IP addresses to each HTTPS service.

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

　　

Use multiple names to generate an SSL Certificate

There are other ways to solve the above problems, but each has its own shortcomings. one way is to change the SubjectAltName field when generating the certificate, for example, www.example.com and www.example.org, but this field has a length limit.

Another way is to use wildcard characters in the certificate name, for example, * .example.org, but the wildcard name can only be used on the first-level subdomain name. This name can match www.example.org, but cannot match example.org or www.sub.example.org.

The two methods can be combined to fill in example.org and * .example.org in the SubjectAltName field.

It is best to place the multi-domain certificate and private key in the configuration http block so that all services can inherit this configuration.

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