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

Deployment of HTTPS on Nginx depends on OpenSSL libraries and include files, that is, libssl-dev (or OpenSSL) must be installed first, and ln-s / usr/lib/x86_64-linux-gnu/libssl.so / usr/lib/, must then specify-- with-http_ssl_module and-- with-http_v2_module when compiling and configuring Nginx. In addition, if you want to run the openssl command locally, install the OpenSSL package and use your own OpenSSL-1.0.2g. Note: the operation examples on Ubuntu 16.04 are used in this paper.

The following figure shows the signing and verification principles of a digital certificate (a public key certificate signed by CA used in HTTPS):

TLS secures the transmission of information: for each new conversation (connection handshake phase. The conversation here is not the application layer conversation involved in HTTP, but the TLS conversation). Both the client and the server negotiate a conversation key and a symmetric encryption algorithm (for more information, please see "encryption Suite" and "four-way handshake") to encrypt and decrypt information, so as to avoid asymmetric encryption and decryption taking too long and faster, while Public/Private key pairs are only used for "pre-master key" encryption and decryption. In particular, after the connection is disconnected, the recovery of the old conversation (two implementation methods: session ID and session ticket) does not belong to the establishment of a new conversation, and there is no need to negotiate a new conversation key and symmetric encryption algorithm.

HTTP2:HTTP2 is based on SPDY design and supports HTTPS. However, unlike SPDY, HTTP2 does not force the use of HTTPS, but there is currently no browser support; the compression algorithm of the HTTP2 header uses HPACK rather than the DELEFT adopted by SPDY. HTTP2 is basically compatible with the semantics of HTTP1.x, but it changes the transmission mode of HTTP1.x. Whether or not to use HTTP2 in a connection is decided by protocol negotiation (NPN, ALPN, or Upgrade header). HTTP2 has many new features:

Binary protocol: HTTP2.0 protocol uses binary format, which is convenient and robust to implement; HTTP1.x uses text format.

Header compression: every time HTTP/1.x requests, it carries a lot of redundant header information, which wastes a lot of bandwidth resources. Header compression can solve this problem very well.

Multiplexing: multiple requests and responses are done concurrently over a single TCP connection, and support for request prioritization and flow control

Server Push: the server can actively push JS and CSS files to the client without requiring the client to parse the HTML before sending these requests. When the client needs it, they are already on the client.

The following figure is in HTTP2 Frame format: RFC7540-Hypertext Transfer Protocol Version 2 (HTTP/2)

Deploy HTTPS + HTTP2 on Nginx

Self-issuing certificate: in the development test environment, you can generate certificates on other machines, and then copy a copy of the generated server.crt and server.key to Nginx's / usr/local/nginx/conf.

$cd / usr/local/nginx/conf$ openssl genrsa-des3-out server.key 1024 # recommendation: 2048$ openssl req-new-key server.key-out server.csr # Certificate signing request (CSR) $cp server.key server.key.org$ openssl rsa-in server.key.org-out server.key$ openssl x509-req-days-in server.csr-signkey server.key-out server.crt # Certificate signature

Modify the configuration file nginx.conf: to reduce the CPU load, it is recommended to run only one worker process and turn on keep-alive. In addition, the default associated directory for Nginx ssl_certificate and ssl_certificate_key above version 0.6.7 is the directory where nginx.conf is located, and the default file name is cert.pem.

Worker_processes 1 is the server {server_name YOUR_DOMAINNAME_HERE; listen 443 ssl http2;# http2 is available only since OpenSSL version 1.0.2 listen 80; if ($scheme = http) {rewrite ^ (. *) $https://$server_name$1 permanent;} ssl_certificate server.crt; ssl_certificate_key server.key; keepalive_timeout 70;}

Restarting the deployment of Nginx:HTTPS on Nginx is almost complete, and then you can access it at ht t ps: / / YO U R _ D OM An I N N A ME _ H E R E. Because the self-issued certificate is used in this example (different from the CA self-signed Root certificate), you will see the warning message as shown in the figure under Chrome, indicating that the certificate is not trusted. By default, browsers have built-in Root certificates from CA institutions, which are absolutely trusted.

In addition, I confirmed that HTTP2 was successfully enabled under Chromium 58.0.3029.110 and Firefox 53.0.3:

Private key protection: the private key is an important property, so limit the people who have access to the private key as much as possible.

Generate the private key and CSR (Certificate Signing Requests) on a trusted computer. There are some CA that will generate keys and CSR for you, but this is obviously inappropriate.

Password-protected keys can prevent interception in the backup system

After finding that it has been intercepted, withdraw the old certificate and generate a new key and certificate.

Update the certificate every year, always using the latest private key

Deployment certificate chain: a certificate chain (Certificate Chain), which includes a trust anchor (CA certificate) and a signed certificate, is a sequence of certificates issued by a series of CA certificates that ends with the root CA certificate; Web browsers have pre-configured a set of root CA certificates that the browser automatically trusts, and all certificates from other certificate authorities must be accompanied by a certificate chain to verify the validity of these certificates. In many deployment scenarios, a single server certificate is insufficient, while multiple certificates need to establish a chain of trust. A common problem is to correctly configure the server certificate but forget to include the other required certificates. In addition, although other certificates usually have a long validity period, they also expire, and if they expire, they affect the entire chain. An invalid certificate chain can lead to invalidation of server certificates and warnings from client browsers, which is sometimes not so easy to detect because some browsers can reconstruct a complete trust chain themselves while others cannot. About the deployment of certificate chains on Nginx:

If you have a chain certificate file (sometimes called an intermediate certificate) you don't specify it separately like you do in Apache. Instead you need to add the information from the chain cert to the end of your main certificate file. This can be done by typing "cat chain.crt > > mysite.com.crt" on the command line. Once that is done youwon't use the chain cert file for anything else, you just point Nginx to the main certificate file

The following figure shows how the certificate chain works:

SSL configuration instruction on Nginx: only part of it is listed below. For more configuration items, please see http://www.nginx.cn/doc/optional/ssl.html.

Ssl: enable HTTPS

Syntax:ssl [on | off]

Default:ssl off

Context:main, server

Ssl_certificate: the certificate file, the default certificate and key are located in cert.pem, and this file can also contain other certificates. Since version 0.6.7, the default associated directory for ssl_certificate is the directory where nginx.conf is located.

Syntax:ssl_certificate file

Default:ssl_certificate cert.pem

Context:main, server

Ssl_certificate_key: certificate key file. The default key is in cert.pem. Since version 0.6.7, the default associated directory for ssl_certificate_key is the directory where nginx.conf is located.

Syntax:ssl_certificate_key file

Default:ssl_certificate_key cert.pem

Context:main, server

Ssl_client_certificate:Indicates file with certificates CA in PEM format, utilized for checking the client certificates.

Syntax:ssl_client_certificate file

Default:none

Context:main, server

Ssl_dhparam:Indicates file with Diffie-Hellman parameters in PEM format, utilized for negotiating TLS session keys.

Syntax: ssl_dhparam file

Default: none

Context: main, server

Ssl_ciphers:Directive describes the permitted ciphers. Ciphers are assigned in the formats supported by OpenSSL.

Syntax: ssl_ciphers file

Default: ssl_ciphers all, ADH, RC4, RSA, High, Medime, LOW, SSLv2, exp.

Context: main, server

Ssl_ciphers all, exp. Exp.

Complete list can be looked with the following command:

Openssl ciphers

Ssl_prefer_server_ciphers:Requires protocols SSLv3 and TLSv1 server ciphers be preferred over the client's ciphers.

Syntax: ssl_prefer_server_ciphers [on | off]

Default: ssl_prefer_server_ciphers off

Context: main, server

Ssl_protocols:Directive enables the protocols indicated. Versions above TLS v1.0 are relatively safe. It is best to discard versions below SSLv3, and firmly do not use versions below SSLv2.

Syntax: ssl_protocols [SSLv2] [SSLv3] [TLSv1]

Default: ssl_protocols SSLv2 SSLv3 TLSv1

Context: main, server

Ssl_session_cache:The directive sets the types and sizes of caches to store the SSL sessions.

Syntax:ssl_session_cache off | none | builtin:size and/or shared:name:size

Default:ssl_session_cache off

Context:main, server

Ssl_session_cache builtin:1000 shared:SSL:10m

Ssl_session_timeout:Assigns the time during which the client can repeatedly use the parameters of the session, which is stored in the cache.

Syntax:ssl_session_timeout time

Default:ssl_session_timeout 5m

Context:main, server

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.