Java Platform Security

j2ee| Security

Installing and configuring SSL support

What is secure Socket layer technology?

Secure Socket Layer (SSL) is a technology that allows Web browsers and Web servers to be connected based on a secure connection. In this secure connection, the data to be transferred is encrypted before it is transmitted, and then decrypted before processing the data immediately after it is received. Both the browser and the server encrypt all the transmitted content before sending any data. SSL primarily handles the following important security issues.

L Certification

In your initial attempt to communicate with a Web server based on a secure connection, the server will give your Web browser a collection of certificates in the form of a server certificate. The purpose of this certificate is to verify who this site is and what he claims to be. In some cases, the server may need a certificate about who the client is and what he claims to be (this is called the client authentication).

• confidentiality

Third parties can see and intercept data when the data is transmitted between the client and the server on the Internet. The SSL answer is encrypted, so the data is not decrypted by the third party and can remain confidential.

L Integrity

Third parties can see and intercept data when the data is transmitted between the client and the server on the Internet. SSL helps ensure that data is not modified by third parties during transmission.

To install and configure SSL support on your stand-alone Web server, you need the following artifacts. If you are using the j2ee1.4 application server, SSL support is already available. If you are using a different Web server, refer to your product documentation.

L Server Certificate key store (reference setting up Digital certificates,page 933).

L HTTPS connector (reference configuration SSL connector, page 939).

To verify that SSL support is available, reference validates SSL Support (page 939).

Installing digital certificates

Note: The digital certificate for the j2ee1.4 application server has been generated and can be found in the directory <j2ee_home>/domains/domain1/config.

In order to use the SSL,J2EE server for each external interface or IP address must have an associated certificate, this can achieve a secure connection. The rationale for this design is that a server must provide some reasonable assurance as to who the owner is, especially before receiving certain sensitive information. The idea that a certificate is a driver's license for a number of network addresses is useful. It shows which company the site is linked to, and describes some basic contact information about the site owner or administrator.

A digital certificate is encrypted by its owner and is difficult to forge by others. A certificate may be purchased from a reputable certification authority (CA), such as VeriSign or Thawte, for a business transaction that is important for a site that is included in an e-commerce or some other identity authentication.

If authentication is not really important, for example, if the administrator simply wants to verify that the data transmitted and received by the server is private and cannot be stolen by someone listening to the connection, you can simply save the time and expense of buying the CA certificate by using your own signed certificate.

SSL uses public key cryptography, which is based on a key pair. A key pair includes a public key and a private key. If the data is encrypted with a key, it can only be decrypted with another key. This feature is the basis for building trust and secrecy in transmission. For example, using SSL, the server computes a value and encrypts the value with the private key. The encrypted value is called a digital signature. The client decrypts the encrypted value using the server's public key and compares the value to its own computed value. If these two values match, the client can trust that the signature is authenticated because only the private key can be used to produce such a signature.

Digital certificates are used to authenticate Web clients in the HTTPS protocol. The HTTPS service for most Web servers will not run unless the digital certificate is installed. Use the following approximate procedure to create a digital certificate that can be used by your Web server to activate SSL.

A tool that can be used to establish a digital certificate is Keytool, a key and certificate management tool with j2ee1.4 application servers. It enables users to manage their own public key private key pairs and associated certificates, in order to be used in self-authentication (the user is to authenticate themselves to another user or service) or data integrity and digital signature authentication services. It also allows users to hide their contact's public key (in the form of a certificate). To better understand key-tool and public key cryptography, read the Keytool documentation, which is as follows:

http://java.sun.com/j2se/ 1.4.2/docs/tooldocs/solaris/key-tool.html

Create a server certificate

The server's certificate has been created for the j2ee1.4 application server. Certificates can be found in the <j2ee_home>/domains/domain1/config/directory. The server certificate is in Keystore.jks. The client certificate is in the Cacerts.jks file.

If necessary, you can use Keytool to generate certificates. Keytool stores keys and certificates in a file corresponding to the KeyStore. KeyStore is a warehouse that stores certificates for confirming clients and servers. Typically, a keystore contains the identity of a client or a server. The default KeyStore treats KeyStore as a file. It protects the private key with a password.

KeyStore is created in the directory where you run Keytool. This directory can be the directory where the application resides, or it can be a common directory for many applications.

In order to create a server certificate,

1. Create KeyStore.

2. Export the certificate from the KeyStore.

3. Signing certificate.

4. Import the certificate into a trust-store. Trust-store refers to a certificate warehouse that is used to verify certificates. A trust-store typically contains more than one certificate. An example of a mutual authentication using Trust-store based on SSL will be discussed in Example:client-certificate authentication over Http/ssl with Jax-RPC (page 950).

Run Keytool to produce the keystore of the server, we name it server-key-store.jks. This step uses the alias Server-alias to generate a new public and private key pair, and packages the public key into a Server-keystore.jks self-signed certificate. This key pair is generated using the RSA algorithm and a default Changeit password. For more information about the Keytool option, check out its online help, address

Http://java.sun.com/j2ee/1.4.2/docs/tooldocs/solaris/keytool.html.

Run Keytool with the following parameters in the directory where you want to create KeyStore. When you press ENTER, Keytool prompts you to enter the server name, organizational unit, organization, location, country, country code. Note that you must enter the name of the server in the answer to the first prompt for Keytool, which requires the initial and last name. With the aim of carrying out the experiment, it can be localhost. The host specified in KeyStore must match the definition in the host variable <install>/j2eetutorial14/examples/common/buid.properties.

1. Generate server certificate.

<java_home>\bin\keytool-genkey-alias server-alias-keyalg rsa-keypass Changeit-storepass changeit-keystore Keystore.jks

2. Export the certificate produced in Keystore.jks to the file server.cer.

<java_home>\bin\keytool-export-alias Server-alias

-storepass changeit-file Server.cer-keystore Keystore.jks

3. If you want to have a certificate issued by a CA, please read signing Digital Certificates (page 937) for more information.

4. To create the Trust-store file Cacerts.jks and add the server certificate to this trust-store, you must run the Keytool in the directory where you created KeyStore and server certificates with the following parameters.

<java_home>\bin\keytool-import-v-trustcacerts

-alias Server-alias-file Server.cer

-keystore Cacerts.jks-keypass Changeit

-storepass Changeit

Certificate information, such as those shown below, will be displayed.

<INSTALL>/J2EETUTORIAL14/EXAMPLES/GS 60% Keytool-import

-v-trustcacerts-alias Server-alias-file Server.cer

-keystore Cacerts.jks-keypass Changeit-storepass Changeit

Owner:cn=localhost, Ou=sun Micro, O=docs, l= Santa Clara,

St=ca, C=us

Issuer:cn=localhost, Ou=sun Micro, O=docs, l= Santa Clara,

St=ca, C=us

Serial number:3e932169

Valid From:tue APR 08

Certificate fingerprints:

md5:52: 9f:49:68:ed:78: 6f:39:87:f3:98:b3: 6a:6b: 0f:90

SHA1:EE:2E: 2a:a6:9e:03: 9 A: 3 A: 1c:17: 4a:28:5e:97:20:78: 3F:

Trust this certificate? [No]:

5. Enter Yes, and then tap enter or return key. The following information will appear.

Certificate is added to KeyStore

[Saving Cacerts.jks]

Issue a digital certificate

Once you create a digital certificate, you will want it to be signed by its owner. Once a digital certificate is encrypted by its owner, it is difficult for him to be forged by others. For business transactions that are important for e-commerce sites or other identity certifications, certificates can be purchased from reputable certification authorities (CAS) such as VeriSign or Thawte.

If authentication is not important, for example, if the administrator simply wants to simply confirm that the data transmitted and received by the server is private and that no other eavesdropping on the connection is heard, you can simply save the time and expense of purchasing the CA certificate by using the self-signed certificate.

Create a client certificate for mutual authentication

This section discusses the authentication of installing a client. When the authentication of the server and the client is available, it is called mutual or two-way authentication. In client authentication, the client needs to submit a certificate issued by the CA you choose to accept. Run Keytool as shown below in the directory where you want to create the client certificate. When you press ENTER, Keytool prompts you to enter the server name, organizational unit, organization, address, country, country code. Note that you must enter the name of the server in the answer to the first prompt for Keytool, which requires the initial and last name. With the aim of carrying out the experiment, it can be localhost. The host specified in KeyStore must match the definition in the host variable <install>/j2eetutorial14/examples/common/buid.properties.

To create a keystore named Client-keystore.jks that contains a client certificate named Client.cer, follow these steps:

1. Create a customer certificate.

<java_home>\bin\keytool-genkey-alias Client-alias-keyalg

Rsa-keypass Changeit-storepass Changeit

-keystore Keystore.jks

2. Export the resulting client certificate to the Client.cer file.

<java_home>\bin\keytool-export-alias Client-alias

-storepass changeit-file Client.cer-keystore Keystore.jks

3. Add the certificate to the Trust-store file Cacerts.jks. In the directory where you create the KeyStore and client certificates, run Keytool with the following parameters:

<java_home>\bin\keytool-import-v-trustcacerts

-alias Client-alias-file Client.cer

-keystore Cacerts.jks-keypass Changeit

-storepass Changeit

Keytool returns the following information:

Owner:cn=j2ee Client, Ou=java Web Services, O=sun, L=santa

Clara, St=ca, C=us

Issuer:cn=j2ee Client, Ou=java Web Services, O=sun, L=santa

Clara, St=ca, C=us

Serial number:3e39e 66a

Valid From:thu 18:58:50 PST 2003 until:wed APR 30

19:58:50 PDT 2003

Certificate fingerprints:

MD5: 5a:b0: 4c:88:4e:f8:ef:e9:e5:8b:53:bd:d0:aa:8e: 5A

SHA1:90:00:36:5B:E0:A7:A2:BD:67:DB:EA:37:B9:61:3E:26:B3:89:46:

32

Trust this certificate? [No]: Yes

Certificate is added to KeyStore

An example application using mutual authentication, see Example:client-certificate authentication over Http/ssl with Jax-RPC (page 950). In order to obtain information about verifying mutual authentication in operation, see Verifying Mutual Authentication is Running (page 941).

A variety of commands about certificates

L to verify the contents of the KeyStore containing the certificate, use the alias Server-alias:

Keytool-list-keystore Keystore.jks-alias Server-alias-v

L Verify the contents of Cacerts documents:

Keytool-list-keystore Cacerts.jks

Configuring SSL Connectors

An SSL connector is configured in advance for the j2ee1.4 application server. You don't have to configure anything.

Verifying SSL Support

Hold the test and verify that SSL support has been properly installed for the purpose of loading the default introduction page with a URL that is linked to the port defined in the server deployment descriptor:

https://localhost:1043

HTTPS in this URL indicates that the browser should be using the SSL protocol. In this example, localhost assumes that you are running this example on your local machine as part of the deployment process. The 1043 in the example is the security port specified at the location where the SSL connector was created when the SSL connector was configured (page 939). If you are using a different server or port, change the value accordingly.

The first time a user loads this application, the New Site Certificate or Security Alert dialog is displayed. Select next to select Finish when you arrive at the final conversation through a series of dialogues. The certificate will only be displayed at the first time. When you accept these certificates, the behavior of the site will assume that you trust the content.

General tips for running SSL

The SSL protocol is designed to be as efficient and secure as possible. However, encryption/decryption is a process that is computationally expensive from an execution point of view. Running a complete Web application on SSL is not very necessary, and it is customary for a developer to decide which page needs a secure connection and which does not. Pages that may require a secure connection include a login page, a personal information page, a shopping cart payment, or a credit card message that needs to be transmitted. Any page in an application can be simply preceded by an address with https: instead of http: to pass the secure socket request. Any page that absolutely requests a secure connection needs to check the type of protocol that corresponds to the page and take the appropriate action if https: is not specified.

The use of a name based physical host on a secure connection is questionable. This is the limitation of the SSL protocol's own design. The SSL handshake of the client browser that accepts the server certificate must occur before the HTTP request is accessed. As a result, the request information containing the actual host name cannot be judged before authentication, and it is also not possible to issue multiple certificates for an IP address. If all the actual hosts based on an IP address need to authenticate the same certificate, then the addresses of multiple hosts should not interfere with normal SSL operations on the server. But know that most client browsers will compare the server's domain name with the domain name listed in the certificate, and if the domain name does not match, the browser will display a warning to the customer. In general, only address-based hosts are commonly used in SSL for product environments.

Enable mutual authentication based on SSL

This section discusses the certificate for installing the client. When the authentication of the server and the client is available, it is called mutual or two-way authentication. In client authentication, the client needs to submit a certificate issued by the CA you choose to accept. There are at least two ways to turn on client authentication. Whichever you choose, you must enter the location of the KeyStore and the password in the Web server configuration file to turn on SSL, as discussed in configuring the SSL Connector (page 939). The two mutual authentication methods that enable SSL based are as follows:

The L setting ClientAuth to true in the certificate domain. Follow the steps below to complete the setup,

A. If you haven't started the application server yet, start it. The information to start the application server can be found in starting and stopping the Java Application Server (page 91).

B. Start admin Console. The information to start the admin console can be found in the starting Admin Console (page 92).

C. In the admin console tree, expand Security, then expand Realms, and select certificate. The certificate domain is used for all transmissions based on HTTP with SSL.

D. Select Add to add ClientAuth attributes to the server. Enter ClientAuth in the name, and enter true in the value.

E. Click Save to save these new properties.

F. Log out admin Console.

When you open the client's authentication by setting the ClientAuth property to True, the client's authentication will be adopted by all requests for the SSL port specified.

L Use the Deployment tool to set the authentication method to Client-certificate. In this way, the client authentication is only valid for the specified resource controlled by the security constraint. Setting up client authentication in this manner will be discussed in Example:client-certificate authentication over Http/ssl with Jax-RPC (page 950).

Client authentication is performed two times when the client authentication is opened in both of these ways.

Verify that mutual authentication is running

You can verify that mutual authentication is working by obtaining the debug information. This is done on the client side, and this example shows how to pass a system attribute in Targets.xml to allow Targets.xml to generate a client that has javax.net.debug in the system properties, which can be added to such as <install>/ J2eetutorial14/examples/security/common/targets.xml file.

In order to make the debug information authenticated by SSL available, you pass system attribute Javax.net.debug=ssl,handshake, which provides information about whether mutual authentication is running. The following examples follow the <instal>/j2eetutorial14/examples/

The Security/common/targets.xml file defines the Run-mutualauth-client task by adding the Sysproperty as shown in bold:

<target name= "Run-mutualauth-client"

Description= "runs a client with mutual authentication over

SSL ">

<java classname= "${client.class}" fork= "yes" >

<arg line= "${key.store} ${key.store.password}"

${trust.store} ${trust.store.password}

${endpoint.address} "/>

<sysproperty key= "Javax.net.debug" Value= SSL,

Handshake "/>

<sysproperty key= "Javax.net.ssl.keyStore"

Value= "${key.store}"/>

<sysproperty key= "Java.net.ssl.keyStorePassword"

Value= "${key.store.password}"/>

<classpath refid= "Run.classpath"/>

</java>

</target>