PHP programmers play with HTTPS in the Linux series Nginx

PHP programmers play with Linux series:

1.PHP programmers play with Linux series - how to install and use CentOS

2.PHP programmers play with the Linux series - building the lnmp environment

3.PHP programmers play with the Linux series - building the FTP code development environment

4.PHP programmers play with the Linux series - backup restore MySQL

5.PHP programmers play with the Linux series - automatic backup with SVN

6.PHP programmers play with the Linux series -Linux and Windows install nginx

7.PHP programmers play with the Linux series -nginx beginner guide

Create an HTTPS server

In the nginx.conf configuration file, specify the ssl parameters through the listen directive in the server block, and set the path of the server certificate and private key files

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;
 ...
}

The server certificate is a public entity that is sent to each connected client. The private key is a secure entity that should be stored in a file with restricted permissions. However, the master process of nginx must be able to read the private key file. The private key can also be placed in a file with the certificate.

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

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

The ssl_protocols and ssl_ciphers directives can be used to restrict connections to only the higher versions of TLS and SSL/TLS passwords

Starting with version 1.0.5 of nginx,nginx defaults to ssl_protocols SSLv3 TLSv1 and ssl_ciphers HIGH:! aNULL:! MD5. Starting with nginx 1.1.13 and 1.0.12, ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2 is updated by default

1 single 1 HTTP and HTTPS services

One service can be configured to support both HTTP and HTTPS requests, using the listen directive in the virtual host, one with ssl parameters, and one without.

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 independently configured to listen to socket. HTTP/HTTPS can only be supported when SSL is enabled for all server. To solve this problem, ssl has been added to listen.

Name based HTTPS service

A common problem arises when listening to two or more HTTPS services at an ip address configuration.

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, which in this case is the www.example.com certificate. This is due to the SSL protocol itself.

The best way to solve this problem is to assign a different IP address 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;
 ...
}

Generate SSL certificates with multiple names

There are other ways to solve the above problem, but each has its own disadvantages. One way is to change the SubjectAltName field when generating the certificate, such as www.example.com and www.example.org, but this field has a length limit.

Another 1 kind of way is use a wildcard certificate name there, such as: *. example. org, but wildcards can only be used on the 1st level subdomain name. This name can match www. example. org, but can't match example. org or www. sub. example. org

These two methods can be combined by entering example.org and *.example.org in the SubjectAltName field

It is best to place multiple domain certificates and private keys 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;
 ...
}