Https principle and tomcat configuration https method, tomcathttps

Https principle and tomcat configuration https method, tomcathttps

• What is HTTPS

Before talking about HTTPS, let's talk about HTTP. HTTP is a protocol we usually use when Browsing webpages. Data transmitted over HTTP is not encrypted, that is, plaintext. Therefore, it is extremely insecure to transmit private information over HTTP. In order to ensure that the private data can be encrypted, Netscape designed the SSL (Secure Sockets Layer) protocol to encrypt the data transmitted over HTTP, which gave birth to HTTPS. The current SSL version is 3.0, which is defined by the IETF (Internet Engineering Task Force) in RFC 6101. Later, the IETF upgraded SSL 3.0, so Transport Layer Security (TLS) emerged) 1.0, defined in RFC 2246. In fact, our current HTTPS uses the TLS protocol, but SSL is still supported by the browser because it appears earlier. Therefore, SSL is still synonymous with HTTPS, but TLS and SSL are things of the last century. The last SSL version is 3.0. In the future, TLS will inherit the fine SSL lineage and continue to provide encryption services for us. Currently, TLS version 1.2 is defined in RFC 5246 and is not widely used yet.

• How Https works

  HTTPS requires a handshake between the client (browser) and the server (website) before data transmission. During the handshake, the password information of both parties for encrypted data transmission is established. The TLS/SSL protocol is not only a set of encrypted transmission protocols, but also a work of art carefully designed by the artist. TLS/SSL uses asymmetric encryption, symmetric encryption, and HASH algorithms. The handshake process is described as follows:

1. the browser sends a set of encryption rules that it supports to the website.

2. The website selects a set of encryption algorithms and HASH algorithms, and sends the identity information to the browser in the form of a certificate. The certificate contains the website address, the encrypted public key, and the certificate authority.

3. After obtaining the website certificate, the browser should do the following:

A) verify the validity of the certificate (whether the certificate issuing authority is legal, whether the website address contained in the certificate is consistent with the address being accessed). If the certificate is trusted, A small lock header is displayed in the browser bar. Otherwise, a message indicating that the certificate is untrusted is displayed.

B) if the certificate is trusted or the user accepts the untrusted certificate, the browser generates a random number of passwords and encrypts them with the public key provided in the certificate.

C) use the agreed HASH to calculate the handshake message, encrypt the message using the generated random number, and finally send all the previously generated information to the website.

4. After the website receives data from the browser, perform the following operations:

A) use your own private key to decrypt the information and retrieve the password, use the password to decrypt the handshake message sent by the browser, and verify that the HASH is consistent with the one sent by the browser.

B) Use the password to encrypt a handshake message and send it to the browser.

5. the browser decrypts and computes the HASH of the handshake message. If the HASH sent from the server is the same, the handshake process ends, after that, all the communication data will be encrypted by the random password generated by the browser using the symmetric encryption algorithm.

Here, the browser and the website send and verify encrypted handshake messages to ensure that both parties have obtained the same password and can encrypt and decrypt data normally, perform a test for subsequent real data transmission. In addition, HTTPS generally uses the following encryption and HASH algorithms:

Asymmetric encryption algorithms: RSA, DSA/DSS

Symmetric encryption algorithms: AES, RC4, 3DES

HASH Algorithm: MD5, SHA1, SHA256

The asymmetric encryption algorithm is used to encrypt the generated password during the handshake process. The symmetric encryption algorithm is used to encrypt the actually transmitted data, while the HASH algorithm is used to verify the data integrity. Because the password generated by the browser is the key to data encryption, asymmetric encryption is used during transmission. Asymmetric encryption algorithms generate public keys and private keys. The public keys can only be used to encrypt data. Therefore, they can be transmitted at will. The private keys of websites are used to decrypt data, therefore, the website will be very careful to keep its own private key to prevent leakage.

If any error occurs during the TLS handshake, the encrypted connection is disconnected, thus blocking the transmission of private information.

**

-Use the tomcat server to configure https two-way authentication

** Generate a certificate for the server **

"Run" console, go to the % JAVA_HOME %/bin directory, and run the following command to enter the directory:
Cd "c: \ Program Files \ Java \ jdk1.6.0 _ 11 \ bin"
Use keytool to generate a certificate for Tomcat. Assume that the domain name of the target machine is "localhost", and the keystore file is stored in "D: \ home \ tomcat. keystore ", password is" password ", generated using the following command:
Keytool-genkey-v-alias tomcat-keyalg RSA-keystore D: \ home \ tomcat. keystore-validity 36500
(Brief description of parameters: "D: \ home \ tomcat. "keystore" indicates the path to save the Certificate file. The certificate file name is tomcat. keystore; "-validity 36500" indicates the certificate validity period. "36500" indicates July 22, 100. The default value is 90 days. "tomcat" indicates the custom certificate name ).

Enter the required parameters in the command line:
A. Enter the keystore password: enter A string greater than 6 characters.

B. "What is your first name and last name ?" This is required and must be the domain name or IP address of the TOMCAT deployment host [for example, gbcom.com or 10.1.25.htm] (that is, the access address you will enter in the browser in the future ), otherwise, a warning window is displayed, prompting that the user certificate does not match the domain. During local development and testing, enter "localhost ".

C. What is your organizational unit name ?" "What is your organization name ?" "What is the name of your city or region ?" "What is the name of your state or province ?" "What is the two-letter country code for this unit ?" You can enter the required information or press enter without entering it. In the system, ask "Is it correct ?" If the requirements are met, enter the letter "y" on the keyboard. Otherwise, enter "n" to fill in the above information.

D. Enter the primary password. This is important and will be used in the tomcat configuration file. We recommend that you enter the same password as the keystore. You can set other passwords, press enter to find the generated file at the position defined in step 2.

Generate a certificate for the client
Generate a certificate for the browser so that the server can verify it. To smoothly import the certificate to IE and Firefox, the certificate format should be PKCS12. Therefore, use the following command to generate the certificate:
Keytool-genkey-v-alias mykey-keyalg RSA-storetype PKCS12-keystore D: \ home \ mykey. p12(Mykey is custom ).

The corresponding certificate inventory is placed in "D: \ home \ mykey. p12", and the client's CN can be any value. Double-click the mykey. p12 file to import the certificate to the browser (client ).

Allow the server to trust the client certificate

Because it is a two-way SSL authentication, the server must trust the client certificate, therefore, the client certificate must be added as the server's trust authentication. Because the PKCS12 certificate library cannot be imported directly, you must first export the client certificate as a separate CER file and run the following command:
Keytool-export-alias mykey-keystore D: \ home \ mykey. p12-storetype PKCS12-storepass password-rfc-file D: \ home \ mykey. cer

(Mykey is the same as the custom mykey of the client. password is the password you set ). With the preceding command, the client certificate is exported to the "D: \ home \ mykey. cer" file.

The next step is to import the file to the server's certificate library and add it as a trusted certificate using the command below:
Keytool-import-v-file D: \ home \ mykey. cer-keystore D: \ home \ tomcat. keystore

Run the list command to view the server certificate library. You can see two certificates: one is the server certificate and the other is the trusted client certificate:
Keytool-list-keystore D: \ home \ tomcat. keystore(Tomcat sets the server certificate name for you ).

Let the client trust the server certificate
Because it is a two-way SSL authentication, the client also needs to verify the server certificate, therefore, you must add the server certificate to the browser "Trusted Root Certificate Authority ". Because the certificate library in keystore format cannot be imported directly, you must first export the server certificate as a separate CER file and use the following command:

Keytool-keystore D: \ home \ tomcat. keystore-export-alias tomcat-file D: \ home \ tomcat. cer(Tomcat sets the server certificate name for you ).

With the preceding command, the server certificate is exported to the "D: \ home \ tomcat. cer" file. Double-click the tomcat. cer file, follow the prompts to install the certificate, and enter the Certificate in "Trusted Root Certificate Authority ".
Configure Tomcat server
Open/Conf/server. xml, Find the Connector port = "8443" configuration section and change it to the following:
**