Principle and configuration usage of HTTPS security protocol

HTTPS principle the client sends a request server to the server to send the client its own certificate client to verify the validity of the certificate (whether it is a certificate issued by a credit institution CA, if not a warning) and if the information is correct, do not pass then disconnect immediately Send your own certificate to the server side and the supported encryption algorithm list server side verifies the validity of the client certificate, and chooses the encryption algorithm with the highest encrypt degree, and then sends the client's public key to decrypt the encryption algorithm to use with its private key. Then randomly generate the main password key in the server-side of the public key to encrypt and send the server with its own private key decryption to obtain the main password after the message sent by the symmetric encryption of encrypted communication

HTTPS has one-way and bidirectional validation, and their differences
One-way authentication only requires the site to deploy SSL certificates on the line, any user can access (IP is restricted, etc.), but the service side provides identity authentication. And two-way authentication is the need for the client to provide identity authentication, can only be server-side allow customers to access, security relative to a higher number of
Bi-directional authentication of the SSL protocol specific communication process, this situation requires both the server and the client have a certificate. The one-way authentication SSL protocol does not require the client to own the CA certificate, and when the symmetric cipher scheme is negotiated, the server sends the client a cryptographic scheme that is not encrypted (this does not affect the security of the SSL process). In this way, both sides of the specific communication content, is encrypted data. If a third party attack, only to obtain encrypted data, the third party to obtain useful information, you need to decrypt the encrypted data, this time the security depends on the security of the password scheme. Fortunately, the current cryptographic scheme, as long as the communication key length is long enough, is sufficient security. This is why we emphasize the need to use 128-bit encrypted communication.
General Web applications are one-way authentication, the reason is very simple, a wide range of users, and do not need to do in the communication layer to do user authentication, generally in the application of the logic layer to ensure that the user's legal login. However, if the enterprise application docking, the situation is not the same, may require the client (relative) to do authentication. Then you need to do two-way authentication.

Tomcat configuration one-way HTTPS

1. Use the Keytool tool in JDK to generate certificate library files and copy them to Tomcat's Conf directory

Keytool-genkey-v-alias tomcat-keyalg rsa-keystore d:/ssl/server/tomcat.keystore-dname "CN=localhost,OU=zlj,O=zlj,L =PEKING,ST=PEKING,C=CN "-validity 3650-storepass 123456-keypass 123456

2. Modify Tomcat's Server.xml file (Keystorefile can be specified by relative path)

<connector     
    port= "8443" maxhttpheadersize= "
    8192" maxthreads= "" "minsparethreads=" maxsparethreads= "Enablelookups=" "
    false" 
    disableuploadtimeout= "true"
    acceptcount= "Scheme=" HTTPS "
    secure=" true "
    clientauth=" false "sslprotocol=" TLS " 
    keystorefile=" Conf/tomcat.keystore " 
    keystorepass= "123456"/>

3. Configure URLs that require the HTTPS protocol to be enforced

 <!--enforce SSL configuration, that is, normal requests will also be redirected to SSL requests--> <security-constraint> <web-resource-collection> <web-resource-name>SSL</web-resource-name> <url-pattern>/service/*</url-patt ern><!--full station using SSL <url-pattern>/*</url-pattern>--> </web-resource-collection> &L T;user-data-constraint> <description>ssl required</description> <!--CONFIDENTIA L: To ensure that data transmitted between the server and the client cannot be modified and cannot be viewed by a third party--> <!--INTEGRAL: To ensure that the data transmitted between the server and clients cannot be modified--> & lt;! -NONE: Indicates that the container must be able to provide data on a any connection. (that is, HTTP or HTTPS, determined by the client)--> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </ User-data-constraint> </security-constraint>