Developing HTTPS applications

Developing HTTPS Applications

SSL, or Secure Socket Layer, is a technology that allows Web browsers and Web servers to communicate through a secure connection. This means that the data being sent is translated into a password at one end, sent out, and then solved by unlocking the password at the other end. This is a two-way process in which both the browser and the server need to encrypt the data before sending it.
Another important aspect of the SSL protocol is authentication (authentication). This means that when you start trying to communicate with a Web server through a secure connection, the server will ask your browser to show a set of credentials, proving that this is the site you are declaring by "authentication".
In some cases, the server will also require a certificate from your Web browser to prove that you are the person you are talking about. This is known as "Customer Authentication", although in practice it is more used for business-to-business transactions rather than for individual users.
However, most SSL-enabled Web servers do not require client authentication (client authentication).

Certificate

To be able to implement SSL, a Web server must have a corresponding certificate (Certificate) for each external interface (IP address) that accepts a secure connection. The theory of this design is that a server must provide some reasonable assurance that the owner of the server is the person you think it is. This certificate states the company associated with this site, as well as some basic contact information for the owner or system administrator of the site.

The certificate is signed by the owner in the form of a password, which is very difficult for others to forge. For any commercial transaction where e-commerce (e-commerce) websites, or other identity certifications are essential, the certificate is to be purchased from a well-known certification authority (Certificate Authority (CA)) such as VeriSign or Thawte. Such certificates can be verified by electronic technology. In fact, the certification authority will guarantee the authenticity of the certificate issued by it, and if you trust the certification authority to issue the certificate, you can believe that the certificate is valid.

In many cases, certification is not really a concern. The system administrator may only want to ensure that the data that is transmitted and received by the server is secret and will not be connected to the person who stole the line. Fortunately, Java provides a relatively simple command-line tool called Keytool, which can simply produce a "self-signed" certificate. A certificate that is signed by itself is only a user-generated certificate and is not formally registered with a recognized authority, so it is not guaranteed to be authentic. But it can guarantee the security of data transmission.

Certification may be important, perhaps unimportant, and fully determined by the needs of the site.


There are two major steps to configuring SSL with Tomcat:


first, generate certificates


1, under the command line execution:

%java_home%\bin\keytool-genkey-alias Tomcat-keyalg RSA

In this command, Keytool is the tool that comes with the JDK to generate the certificate. The RSA algorithm is used as the primary security algorithm, which guarantees compatibility with other servers and components.
This command will produce a new file called ". KeyStore" in the user's home directory. After execution, you are first asked to show the KeyStore password. The default password used by Tomcat is "Changeit" (all lowercase letters), and you can specify your own password if you wish. You also need to specify your own password in the Server.xml configuration file, which will be described later.

2. You will be asked to produce general information about this certificate, such as company, contact name, etc. This information is displayed to users who try to access secure pages in your program to ensure that the information provided here corresponds to what they expect.

3. You will be required to show the key (key) password, which is the unique password for this certificate (unlike other certificates stored in the same KeyStore file). You must use the same password as the KeyStore password here. (Currently, Keytool will prompt you to press ENTER to automatically do this for you).

If all goes well, you now have a KeyStore file that can be used by your server with a certified certificate.

Ii. Configuring Tomcat


The second big step is to configure the secure socket in the $catalina_home/conf/server.xml file. $CATALINA _home represents the directory where Tomcat is installed. An example is an SSL connector element that is included in the default Server.xml file installed with Tomcat. It looks like this:

The connector element itself, whose default form is commented out (commented out), needs to be removed from the annotation flags around it. Then, you can customized (set yourself) specific properties as needed. Generally need to add keystorefile and Keystorepass two properties, specify the path where you store the certificate (such as: keystorefile= "C:/.keystore") and the password you just set (such as: keystorepass= "123456 "）。 For more information on the various other options, consult the server Configuration Reference.

After you complete these configuration changes, you must restart Tomcat, and then you can access any Web applications that Tomcat supports with SSL. But the instructions need to be like this: https://localhost:8443

Developing HTTPS applications