This article mainly introduces how to set up an HTTPS server for Nginx and force HTTPS access, that is, jump from HTTP to HTTPS. For more information, see
HTTPS Overview
HTTPS (Hyper Text Transfer Protocol Secure) is an HTTP based on SSL/TLS. All HTTP data is transmitted over the SSL/TLS Protocol encapsulation. Based on the HTTP protocol, the HTTPS protocol adds SSL/TLS handshakes and encrypted data transmission, which is also an application layer protocol. The default port used by Https is 443. For more HTTPS principle, refer to the article of teacher Ruan Yifeng: http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html
SSL Certificate
Certificate type Overview
To set up a security server, use the public key to create a pair of public/private key pairs. In most cases, send a certificate request (including your own Public Key), your company's evidentiary materials, and fees to a Certificate Authority (CA ). The CA verifies the certificate request and your identity, and then returns the certificate to your security server.
However, you can encrypt the content transmitted by a server or client on the Intranet. You can issue a certificate to yourself. You only need to ignore alarms that are not trusted by the browser!
The certificate signed by CA provides two important functions for your server:
- The browser automatically recognizes the certificate and allows you to create a secure connection without prompting the user.
- When a CA generates a signed certificate, it provides identity guarantee for organizations that provide web pages to the browser.
Most web servers that support ssl have a CA list and their certificates are automatically accepted. When a browser encounters a certificate whose authorized CA is not in the list, the browser will ask the user whether to accept or reject the connection.
Create a CA certificate
Ca. key CA private key:
Openssl genrsa-des3-out ca. key 2048
Ca. crt CA root certificate (Public Key ):
Openssl req-new-x509-days 365-key ca. key-out ca. crt
Create a website certificate and use the CA signature for authentication
Here, assume that the website domain name is www.example.com and the private key of the com.example.com certificate is generated:
openssl genrsa -des3 -out www.example.com.pem 1024
Make the decrypted private key of the www.example.com certificate:
openssl rsa -in www.example.com.pem -out www.example.com.key
Generate a signature request:
openssl req -new -key www.example.com.pem -out www.example.com.csr
You can enter the website domain Name in the Common Name to produce the certificate for the website.
Use CA for signature:
The Code is as follows:
Openssl ca-policy policy_anything-days 365-cert ca. crt-keyfile ca. key-in www.example.com. csr-out www.example.com. crt
When the signature is executed, the question "I am unable to access the./demoCA/newcerts directory" may occur:
Solution:
mkdir -p demoCA/newcerts touch demoCA/index.txt touch demoCA/serial echo "01" > demoCA/serial
Then, run the Signature command.
Build an https vm Based on Nginx
Virtual Host Configuration File
Upstream sslfpm {server 127.0.0.1: 9000 weight = 10 max_fails = 3 fail_timeout = 20 s;} server {listen 192.168.1. *: 443; server_name 192.168.1. *; # enable ssl for a server to support ssl on; # specify the pem Certificate file ssl_certificate/home/wangzhengyi/ssl/wangzhengyi for the VM. crt; # specify the private key file ssl_certificate_key/home/wangzhengyi/ssl/wangzhengyi_nopass.key for the VM; # The client can reuse the session parameter time stored in the cache ssl_session_timeout 5 m; # ssl_protocols SSLv3 TL Sv1; # specify the license password description ssl_ciphers ALL :! ADH :! EXPORT56: RC4 + RSA: + HIGH: + MEDIUM: + LOW: + SSLv2: + EXP; # The server password requirements of SSLv3 and TLSv1 have a higher priority than the client password ssl_prefer_server_ciphers on; location/{root/home/wangzhengyi/ssl/; autoindex on; autoindex_exact_size off; autoindex_localtime on ;} # redirect server error pages to the static page/50x.html # error_page 500 502 503 x.html; error_page 504/50 .html; location =/50x.html {root/usr/share/nginx/www;} loca Tion =/404.html {root/usr/share/nginx/www;} # proxy the PHP scripts to fpm location ~ \. Php $ {access_log/var/log/nginx/ssl. access. log main; error_log/var/log/nginx/ssl. error. log; root/home/wangzhengyi/ssl/; fastcgi_param HTTPS on; include/etc/nginx/fastcgi_params; fastcgi_pass sslfpm ;}}
HTTPS Server Optimization
Method
SSL operations consume CPU resources. Therefore, in a multi-processor system, you need to start multiple working processes, and the number of available CPUs is not less. The SSL handshake is the most CPU-consuming SSL Operation. There are two ways to minimize the number of handshake operations on each client:
Keep the client persistent connection and send multiple requests in an SSL connection
Use SSL session parameters in concurrent connections or subsequent connections to avoid SSL handshake.
Session cache is used to save SSL sessions. These caches are shared among working processes. You can use the ssl_session_cache command for configuration. The 1 MB cache can store about 4000 sessions. The default cache timeout value is 5 MB. You can use ssl_session_timeout to increase it.
Ssl_session_cache command
Syntax: ssl_session_cache off | none | builtin: size | shared: name: size
Environment: main, server
Cache type:
Off -- hard close. nginx clearly tells the client that this session cannot be reused.
None-soft close, nginx tells the Client Session to be reused, but nginx will not actually reuse them
Bultin -- openssl built-in cache, which can be used only for one worker process. It may cause memory fragmentation.
Shared-the shared cache of all worker processes. (1) cache size specified by number of characters (2) Each cache must have its own name (3) cache with the same name can be used for multiple virtual hosts
Optimization example
# Optimize the ssl Service ssl_session_cache shared: wzy: 10 m; # The client can reuse the session parameter time stored in the cache ssl_session_timeout 10 m;
Nginx enforces https access (http redirects to https)
Built a virtual host for https access based on nginx, the listening domain name is test.com, but many users do not know the difference between https and http, it is easy to knock into the http://test.com, at this time, the 404 error will be reported, so I need to perform an http force redirect to https Based on the test.com Domain Name
Nginx rewrite Method
Ideas
This should be the easiest way to think of. Simply rewrite all http requests to https through rewrite.
Configuration
server { listen 192.168.1.111:80; server_name test.com; rewrite ^(.*)$ https://$host$1 permanent; }
After you build this Vm, You can override all requests from the http://test.com to the https://test.com.
Nginx 497 status code
error code 497 497 - normal request was sent to HTTPS
Explanation: When this virtual site only allows https access, nginx reports a 497 error code when http is used for access.
Ideas
Use the error_page command to redirect the 497 status code link to the https://test.com Domain Name
Configuration
Server {listen 192.168.1.11: 443; # ssl port listen 192.168.1.11: 80; # the user is used to http access and 80 is followed by a 497 status code to automatically jump to port 443 server_name test.com; # For a server {......} enable ssl to support ssl on; # specify the Certificate file ssl_certificate/etc/nginx/test in PEM format. pem; # specify the private key file ssl_certificate_key/etc/nginx/test. key; # redirect an http request to an https request error_page 497 https: // $ host $ uri? $ Args ;}
Index.html
Ideas
Both methods consume server resources. Use curl to access baidu.com and see how Baidu's company redirects baidu.com to www.baidu.com.
We can see that Baidu is clever use of meta Refresh function, the baidu.com to jump to www.baidu.com. So we can be based on the http://test.com of the virtual environment under also write an index.html, the content is http jump to https
index.html