Take you to use Nginx to implement HTTPS bidirectional authentication

HTTPS one-way verification application widely presumably everyone is familiar with, I have shared in a blog post, this time to see how nginx implementation of two-way verification.

Difference between one-way verification and two-way verification:

One-way authentication: The client authenticates the server-side certificate, and the server does not need to validate the client certificate.

Bidirectional authentication: The client authenticates the server-side certificate, and the server needs to authenticate the client certificate through the CA's public key certificate.

A detailed handshake process:

One-way verification

The browser sends a connection request to the secure server.

1. The server sends its own certificate, as well as the information related to the certificate, to the customer's browser.

2. The client browser checks whether the certificate sent by the server is issued by the CA center that you trust. If it is, continue with the agreement; if not, the customer's browser gives the customer a warning message: Warn the customer that the certificate is not trustworthy and asks the customer if it needs to continue.

3, then the customer browser compare the message in the certificate, such as the domain name and public key, and the server just sent the relevant message is consistent, if it is consistent, the client browser recognized the legitimate identity of the server.

4. The browser randomly generates a "call key" for subsequent communication, encrypts it with the server's public key, and then passes the encrypted "pre-master password" to the server.

5, the server from the customer sent over the password scheme, select one of the most encrypted password scheme, with the server's private key to notify the browser.

6, the browser for this password scheme, and then use the server's public key to be sent to the server.

7, the server receives the browser sends the message, uses own private key to decrypt, obtains.

8, the server, the browser next communication is a symmetric cipher scheme, using the same symmetric key.

Two-way verification

1. The browser sends a connection request to the secure server.

2. The server sends its own certificate, as well as the information related to the certificate, to the customer's browser.

3. The client browser checks whether the certificate sent by the server is issued by the CA center that you trust. If it is, continue with the agreement; if not, the customer's browser gives the customer a warning message: Warn the customer that the certificate is not trustworthy and asks the customer if it needs to continue.

4, then the customer browser compare the message in the certificate, such as the domain name and public key, and the server just sent the relevant message is consistent, if it is consistent, the client browser recognized the legitimate identity of the server.

5, the server requires the customer's identity authentication, the user can establish a random number and then digitally sign it, the random number containing the signature and the customer's own certificate and encrypted "pre-master password" together to the server.

6, the server must verify the legality of the customer certificate and signature random number, the specific legality verification process includes: whether the customer's certificate use date is valid, to provide a certificate to the client CA is reliable, the issuing CA's public key can correctly unlock the client certificate of the issuing CA digital signature, Check that the client's certificate is in the certificate revocation list (CRL). If the test is not passed, the communication is interrupted immediately; If authenticated, the server will use its own private key to unlock the encrypted "master password" and then perform a series of steps to generate the primary communication password (the client will also generate the same master communication password in the same way).

7, the Customer browser tells the server itself can support the communication symmetric password scheme.

8, the server from the customer sent over the password scheme, select a cryptographic scheme of the highest encryption, with the customer's public key after the notification browser.

9, the browser for this password scheme, select a call key, and then use the server's public key to be sent to the server.

10. The server receives the message sent by the browser, decrypts it with its own private key, and obtains the call key.

11, the server, the browser next communication is a symmetric cipher scheme, using the same symmetric key.

One, self-built CA, signed certificate

# OpenSSL profile Path vim/etc/pki/tls/openssl.cnf# The following are only a few key instructions in the configuration file and the self-built ca dir =/etc/pki/ca # CA's Working directory database = $dir/index.txt # Sign the certificate's data record file New_certs_dir = $dir/newcerts # The directory that holds the new signing certificate serial = $dir/serial # New Certificate signing number record file Cer Tificate = $dir/CA.CRT # CA's certificate path Private_key = $dir/PRIVATE/CAKEY.PEM # CA's private key path

Using OpenSSL to make a self-signed certificate for a CA

# Switch to the working directory of the CA cd/etc/pki/ca# make CA private key (Umask 077; OpenSSL genrsa-out Private/cakey.pem 2048) # Create a self-signed certificate OpenSSL req-new-x509- Key Private/cakey.pem-out CA.CRT # Generates a data log file, generates a sign-number record file, and gives the file an initial number. Touch Index.txttouch Serialecho ' > serial# self-built CA complete

Preparing the server-side certificate

# Make server-side private key (Umask 077; OpenSSL genrsa-out server.key 1024) # Make server-side certificate request specify use SHA512 algorithm signature (default using SHA1 algorithm) OpenSSL Req-new-key ser Ver.key-sha512-out server.csr# Signing certificate OpenSSL ca-in server.csr-out server.crt-days 3650

Preparing the client certificate

# Make Client private key (Umask 077; OpenSSL genrsa-out kehuduan.key 1024) # make client certificate request OpenSSL Req-new-key kehuduan.key-out KEHUDUAN.CSR # Sign Certificate OpenSSL ca-in kehuduan.csr-out kehuduan.crt-days 3650

Precautions:

1, the certificate will be prompted to enter a password, set the password is optional, the server certificate and client certificate password can be different.

2, the server certificate and the client certificate is prompted to enter the province, city, domain name information, etc., need to remain consistent.

3. The following information root certificate needs to match the client certificate, otherwise there may be a signing issue.

countryname = match
Stateorprovincename = match
OrganizationName = match
Organizationalunitname = match

How to specify the signature algorithm for signing a certificate

OpenSSL req xx-[digest] Digest to sign with (see OpenSSL dgst-h for list)

To view the signature algorithm used:

650) this.width=650; "src=" Http://s1.51cto.com/wyfs02/M01/80/EA/wKiom1dEXMygjao6AABWovfkDhQ536.png "title=" Qq20160524215257.png "alt=" Wkiom1dexmygjao6aabwovfkdhq536.png "/>

# using-sha256 to specify algorithm OpenSSL Req-new-key server.key-sha256-out SERVER.CSR

server {        listen        443;        server_name  pro.server.com;         ssi on;        ssi_silent_errors  on;        ssi_types text/shtml;         ssl                   on;        ssl_certificate       /data/server/nginx/ssl/self/server.crt;         ssl_certificate_key  /data/server/nginx/ssl/self/server.key;         ssl_client_certificate /data/server/nginx/ssl/self/ca/ca.crt;         ssl_verify_client on;        ssl_protocols    tlsv1  tlsv1.1 tlsv1.2;        ssl_ciphers  ecdhe-ecdsa-aes256-gcm-sha384:ecdhe-rsa-aes256-gcm-sha384:ecdhe-ecdsa-aes256-sha384:ecdhe-rsa-aes256-sha384: ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256: ecdhe-ecdsa-rc4-sha:! ecdhe-rsa-rc4-sha:ecdh-ecdsa-rc4-sha:ecdh-rsa-rc4-sha:ecdhe-rsa-aes256-sha:! rc4-sha:high:!anull:!enull:! low:!3des:! md5:! Exp:! Cbc:! edh:!kedh:! Psk:! srp:!kecdh;        ssl_prefer_server_ciphers on;         index index.html index.htm index.php;         root /data/www;        location  ~ .*\. (PHP|PHP5)? $        {                 #fastcgi_pass   unix:/tmp/ php-cgi.sock;                 fastcgi_pass  127.0.0.1:9000;                 fastcgi_index index.php;                 include fastcgi.conf;         }        location ~ .*\. (gif|jpg|jpeg|png|bmp|swf) $        {                 expires 30d;         }        location ~ .*\. (JS|CSS)? $        {                expires 1h;         }## #this  is to use open website  lianjie like on apache##        location / {                 if  (!-e   $request _filename)  {                         rewrite ^ (. *) $ /index.php?s=$1  last;                         break;                 }                  keepalive_timeout  0;        }         location ~ /.svn/ {        deny  all;        }## #end ##         include /data/server/nginx/conf/rewrite/test.conf;         access_log /log/nginx/access/access.log; }

Client certificate Format conversion

# Convert a text-formatted certificate into a certificate that can be imported into the browser OpenSSL pkcs12-export-clcerts-in client.crt-inkey client.key-out client.p12

Third, the certificate into the browser, here in Chrome as an example

1. Locate the settings in the upper right corner of the browser window

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/80/F0/wKiom1dFJK_iAIa0AAByQfijKWM484.png "title=" 1.png " alt= "Wkiom1dfjk_iaia0aabyqfijkwm484.png"/>

2. Find advanced settings in the Setup window

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/80/EF/wKioL1dFJbHSnDwQAABp-IlVvZc593.png "title=" 2.png " alt= "Wkiol1dfjbhsndwqaabp-ilvvzc593.png"/>

3. Find Management Certificate

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M01/80/F0/wKiom1dFJMnR8d3zAACiVLwT94I491.png "title=" 3.png " alt= "Wkiom1dfjmnr8d3zaacivlwt94i491.png"/>

4. Click Import Certificate, then select the certificate path.

650) this.width=650; "src=" Http://s5.51cto.com/wyfs02/M01/80/EF/wKioL1dFJcqz2RcgAABKRZb2kgU814.png "title=" 4.png " alt= "Wkiol1dfjcqz2rcgaabkrzb2kgu814.png"/>

5, after the import of the certificate can be normal access to the server data

650) this.width=650; "src=" Http://s1.51cto.com/wyfs02/M02/80/F1/wKiom1dFJTWTqdbeAACGSlVFFqo683.png "title=" 5.png " alt= "Wkiom1dfjtwtqdbeaacgslvffqo683.png"/>

6, if you do not successfully import the client certificate to access the server, then the Server Authentication client certificate This step will fail, and then return the following error

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M02/80/F1/wKiom1dFJUPzkeUEAABN92QngcQ596.png "title=" 6.png " alt= "Wkiom1dfjupzkeueaabn92qngcq596.png"/>

Because the self-visa book is not trusted by the public CA, there will be a red fork in HTTPS.

This article is from the "Break Comfort zone" blog, so be sure to keep this source http://tchuairen.blog.51cto.com/3848118/1782945

Take you to use Nginx to implement HTTPS bidirectional authentication