Shulou(Shulou.com)05/31 Report--

This article mainly introduces how to use Nginx to achieve HTTPS two-way verification related knowledge, the content is detailed and easy to understand, the operation is simple and fast, has a certain reference value, I believe you will have something to gain after reading this article on how to use Nginx to achieve HTTPS two-way verification, let's take a look.

The difference between one-way and two-way authentication:

One-way authentication: the client verifies the server-side certificate, and the server does not need to verify the client-side certificate.

Two-way authentication: the client verifies the server-side certificate, and the server also needs to verify the client-side certificate through ca's public key certificate.

Detailed handshake process:

One-way verification

The browser sends a connection request to the security server.

1. The server sends its own certificate and information related to the certificate to the client browser.

2. The client's browser checks whether the certificate sent by the server is signed by the trusted ca center. If so, continue to implement the agreement; if not, the customer's browser gives the customer a warning message: warn the customer that the certificate is not reliable and ask the customer if he needs to continue.

3. Then the client browser compares whether the messages in the certificate, such as domain name and public key, are consistent with the relevant messages just sent by the server. If so, the client browser recognizes the legal identity of the server.

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

5. From the password scheme sent by the client, the server chooses a password scheme with the highest degree of encryption, encrypts it with the server's private key and notifies the browser.

6. The browser aims at this password scheme, then encrypts it with the public key of the server and sends it to the server.

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

8. The next communication between the server and the browser is a symmetric cryptographic scheme, using the same symmetric key.

Two-way verification

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

2. The server sends its own certificate and information related to the certificate to the client browser.

3. The client's browser checks whether the certificate sent by the server is signed by the trusted ca center. If so, continue to implement the agreement; if not, the customer's browser gives the customer a warning message: warn the customer that the certificate is not reliable and ask the customer if he needs to continue.

4. Then the client browser compares whether the messages in the certificate, such as domain name and public key, are consistent with the relevant messages just sent by the server. If so, the client browser recognizes the legal identity of the server.

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

6. The server must verify the validity of the client's certificate and the random number of signatures. The specific verification process includes: whether the client's certificate is valid, whether the ca that provides the certificate to the client is reliable, whether the public key of issuing ca can correctly unlock the digital signature of the issuing ca of the client's certificate, and checking whether the client's certificate is in the certificate revocation list (crl). If the verification fails, the communication will be interrupted immediately; if the authentication is passed, the server will unlock the encrypted "pre-master password" with its own private key. Then perform a series of steps to generate the primary communication password (the client will generate the same primary communication password in the same way).

7. The client's browser tells the server the communication symmetric password scheme that it can support.

8. From the password scheme sent by the client, the server selects a password scheme with the highest degree of encryption, and notifies the browser after it is encrypted with the customer's public key.

9. According to this password scheme, the browser selects a call key, then encrypts it with the server's public key and sends it 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 next communication between the server and the browser is a symmetric cryptographic scheme, using the same symmetric key.

Build your own ca and sign the certificate

# openssl configuration file path vim/etc/pki/tls/openssl.cnf# lists only several key instructions related to self-built ca in the configuration file dir=/etc/pki/ca#ca working directory database=$dir/index.txt# signed certificate data record file new_certs_dir=$dir/newcerts# stores the newly signed certificate directory serial=$dir/serial# new certificate signing number record file certificate=$dir/ca.crt#ca certificate path private_ Private key path of key=$dir/private/cakey.pem#ca

Using openssl to make self-signed Certificate of ca

# switch to ca's working directory cd/etc/pki/ca# to make ca private key (umask077;opensslgenrsa-outprivate/cakey.pem2048) # make self-signed certificate opensslreq-new-x509-keyprivate/cakey.pem-outca.crt# to generate data record file, generate signature record file, and give the file an initial number. Touchindex.txttouchserialecho'01' > serial# self-built ca completed

Prepare the server-side certificate

# make server-side private key (umask077;opensslgenrsa-outserver.key1024) # make server-side certificate application specify use sha512 algorithm signature (default use sha1 algorithm) opensslreq-new-keyserver.key-sha512-outserver.csr# sign certificate opensslca-inserver.csr-outserver.crt-days3650

Prepare the client certificate

# making client private key (umask077;opensslgenrsa-outkehuduan.key1024) # making client certificate application opensslreq-new-keykehuduan.key-outkehuduan.csr# signing certificate opensslca-inkehuduan.csr-outkehuduan.crt-days3650

Note:

1. When making a certificate, you will be prompted to enter a password. Setting the password is optional. The password of the server certificate and the client certificate can be different.

2. When making server certificate and client certificate, you are prompted to enter province, city, domain name information, etc., which need to be consistent.

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

Countryname = match stateorprovincename = match organizationname = match organizationalunitname = match

How to specify the signing algorithm for signing certificates

Opensslreqxx- [digest] digesttosignwith (seeopenssldgst-hforlist)

View the signature algorithm used:

# specify algorithm opensslreq-new-keyserver.key-sha256-outserver.csr using-sha256

2. Provide nginx configuration file

Server {listen443;server_namepro.server.com;ssion;ssi_silent_errorson;ssi_typestext/shtml;sslon;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_clienton;ssl_protocolstlsv1tlsv1.1tlsv1.2 Sslophersecdhey256ecdheWAes256MMMMMMKE256GMKS sha384ecdheMy256 gcmSha384aecdheMyecdheWAE256Sha384WEDHUEWEKEKEKEKEKEWEKEKEKEKEWEKEKEKEKEWEKEKEN: Sslash, ciphersecdheWA256MUECdsaA128YOGCMSha256ecdsaFECTECTHAY 128ShaSha256ecdsaeFor A128ShaSha256ecdsaaaaaaA128Sha256ecdsaaaaaa128Sha256aecdsaaaaa128Sha256aecdsaaaaaaaaaaa8Sha256aecdsav ecdsav High:!anull:!enull:!low:!3des:!md5:!exp:!cbc:!edh:!kedh:!psk:!srp:!kecdh Ssl_prefer_server_cipherson;indexindex.htmlindex.htmindex.php;root/data/www;location~.*\. (php | php5)? ${# fastcgi_passunix:/tmp/php-cgi.sock;fastcgi_pass127.0.0.1:9000;fastcgi_indexindex.php;includefastcgi.conf;} location~.*\. (gif | jpg | jpeg | png | swf) ${expires30d;} location~.*\. (js | css)? ${expires1h;} # thisistouseopenwebsitelianjielikeonapache##location/ {if (!-e$request_filename) {if ^ (. *) $/ index.php?s=$1last;break } keepalive_timeout0;} location~/.svn/ {denyall;} # end##include/data/server/nginx/conf/rewrite/test.conf;access_log/log/nginx/access/access.log;}

Client certificate format conversion

# convert a certificate in text format to a certificate opensslpkcs12-export-clcerts-inclient.crt-inkeyclient.key-outclient.p12 that can be imported into a browser

Import the certificate into the browser. Here, take chrome as an example.

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

2. Find the advanced settings in the settings window

3. Find the management certificate

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

5. After importing the certificate, you can access the server data normally

6. If you access the server without successfully importing the client certificate, the server will fail to verify the client certificate and return the following error

Because the self-signed certificate is not trusted by the public ca, there will be a red cross in the https.

This is the end of the article on "how to use Nginx to achieve HTTPS two-way authentication". Thank you for reading! I believe that everyone has a certain understanding of "how to use Nginx to achieve HTTPS two-way verification" knowledge, if you want to learn more knowledge, welcome to follow the industry information channel.

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.