Movatterモバイル変換

Establishing a Secure Connection Using SSL

Secure Socket Layer (SSL) technology is security that is implemented at the transport layer (seeTransport-Layer Security, for more information about transport layer security). SSL allows web browsers andweb servers to communicate over a secure connection. In this secure connection, thedata that is being sent is encrypted before being sent and then isdecrypted upon receipt and before processing. Both the browser and the server encryptall traffic before sending any data. SSL addresses the following important security considerations.

Authentication: During your initial attempt to communicate with a web server over a secure connection, that server will present your web browser with a set of credentials in the form of a server certificate. The purpose of the certificate is to verify that the site is who and what it claims to be. In some cases, the server may request a certificate that the client is who and what it claims to be (which is known as client authentication).
Confidentiality: When data is being passed between the client and the server on a network, third parties can view and intercept this data. SSL responses are encrypted so that the data cannot be deciphered by the third party and the data remains confidential.
Integrity: When data is being passed between the client and the server on a network, third parties can view and intercept this data. SSL helps guarantee that the data will not be modified in transit by that third party.

Installing and Configuring SSL Support

An SSL HTTPS connector is already enabled in the Application Server.

If you are using a different application server or web server, anSSL HTTPS connector might or might not be enabled. If you are usinga server that needs its SSL connector to be configured, consult the documentationfor that server.

As a general rule, to enable SSL for a server, you mustaddress the following issues:

There must be aConnector element for an SSL connector in the server deployment descriptor.
There must be valid keystore and certificate files.
The location of the keystore file and its password must be specified in the server deployment descriptor.

You can verify whether or not SSL is enabled by following thesteps inVerifying SSL Support.

Specifying a Secure Connection in Your Application Deployment Descriptor

To specify a requirement that protected resources be received over a protected transportlayer connection (SSL), specify a user data constraint in the application deployment descriptor.The following is an example of aweb.xml application deployment descriptor thatspecifies that SSL be used:

<security-constraint>    <web-resource-collection>        <web-resource-name>view dept data</web-resource-name>        <url-pattern>/hr/employee/*</url-pattern>        <http-method>GET</http-method>        <http-method>POST</http-method>    </web-resource-collection>    <auth-constraint>        <role-name>DEPT_ADMIN</role-name>    </auth-constraint>    <user-data-constraint>        <transport-guarantee>CONFIDENTIAL</transport-guarantee>    </user-data-constraint></security-constraint>

A user data constraint (<user-data-constraint> in the deployment descriptor) requires that all constrainedURL patterns and HTTP methods specified in the security constraint are received overa protected transport layer connection such as HTTPS (HTTP over SSL). A userdata constraint specifies a transport guarantee (<transport-guarantee> in the deployment descriptor). The choices fortransport guarantee includeCONFIDENTIAL,INTEGRAL, orNONE. If you specifyCONFIDENTIAL orINTEGRALas a security constraint, that type of security constraint applies to all requests thatmatch the URL patterns in the web resource collection and not justto the login dialog box.

The strength of the required protection is defined by the value ofthe transport guarantee.

SpecifyCONFIDENTIAL when the application requires that data be transmitted so as to prevent other entities from observing the contents of the transmission.
SpecifyINTEGRAL when the application requires that the data be sent between client and server in such a way that it cannot be changed in transit.
SpecifyNONE to indicate that the container must accept the constrained requests on any connection, including an unprotected one.

The user data constraint is handy to use with basic and form-baseduser authentication. When the login authentication method is set toBASIC orFORM,passwords are not protected, meaning that passwords sent between a client and aserver on an unprotected session can be viewed and intercepted by third parties.Using a user data constraint with the user authentication mechanism can alleviate thisconcern. Configuring a user authentication mechanism is described inSpecifying an Authentication Mechanism.

Verifying SSL Support

For testing purposes, and to verify that SSL support has been correctly installed,load the default introduction page with a URL that connects to the portdefined in the server deployment descriptor:

https://localhost:8181/

Thehttps in this URL indicates that the browser should be using theSSL protocol. Thelocalhost in this example assumes that you are running theexample on your local machine as part of the development process. The8181in this example is the secure port that was specified where the SSLconnector was created. If you are using a different server or port, modifythis value accordingly.

The first time that you load this application, the New Site Certificate orSecurity Alert dialog box displays. Select Next to move through the series ofdialog boxes, and select Finish when you reach the last dialog box.The certificates will display only the first time. When you accept the certificates, subsequenthits to this site assume that you still trust the content.

Tips on Running SSL

The SSL protocol is designed to be as efficient as securely possible. However,encryption and decryption are computationally expensive processes from a performance standpoint. It isnot strictly necessary to run an entire web application over SSL, and itis customary for a developer to decide which pages require a secure connectionand which do not. Pages that might require a secure connection include loginpages, personal information pages, shopping cart checkouts, or any pages where credit cardinformation could possibly be transmitted. Any page within an application can be requestedover a secure socket by simply prefixing the address withhttps: instead ofhttp:.Any pages that absolutely require a secure connection should check the protocol typeassociated with the page request and take the appropriate action ifhttps isnot specified.

Using name-based virtual hosts on a secured connection can be problematic. This isa design limitation of the SSL protocol itself. The SSLhandshake, wherethe client browser accepts the server certificate, must occur before the HTTP requestis accessed. As a result, the request information containing the virtual host namecannot be determined before authentication, and it is therefore not possible to assignmultiple certificates to a single IP address. If all virtual hosts on asingle IP address need to authenticate against the same certificate, the addition ofmultiple virtual hosts should not interfere with normal SSL operations on the server.Be aware, however, that most client browsers will compare the server’s domain nameagainst the domain name listed in the certificate, if any (this is applicableprimarily to official, CA-signed certificates). If the domain names do not match, these browserswill display a warning to the client. In general, only address-based virtual hostsare commonly used with SSL in a production environment.

Working with Digital Certificates

Digital certificates for the Application Server have already been generated and can befound in the directorydomain-dir/config/. These digital certificates are self-signed and areintended for use in a development environment; they are not intended for productionpurposes. For production purposes, generate your own certificates and have them signed bya CA.

The instructions in this section apply to the developer and cluster profiles ofthe Application Server. In the enterprise profile, thecertutil utility is usedto create digital certificates.

To use SSL, an application or web server must have an associatedcertificate for each external interface, or IP address, that accepts secure connections. The theorybehind this design is that a server should provide some kind of reasonableassurance that its owner is who you think it is, particularly before receivingany sensitive information. It may be useful to think of a certificate asa “digital driver’s license” for an Internet address. It states with which companythe site is associated, along with some basic contact information about the siteowner or administrator.

The digital certificate is cryptographically signed by its owner and is difficult foranyone else to forge. For sites involved in e-commerce or in any otherbusiness transaction in which authentication of identity is important, a certificate can bepurchased from a well-known certificate authority (CA) such as VeriSign or Thawte. If yourserver certificate is self-signed, you must install it in the Application Serverkeystore file (keystore.jks). If your client certificate is self-signed, you should install it inthe Application Server truststore file (cacerts.jks).

Sometimes authentication is not really a concern. For example, an administrator might simplywant to ensure that data being transmitted and received by the server isprivate and cannot be snooped by anyone eavesdropping on the connection. In suchcases, you can save the time and expense involved in obtaining aCA certificate and simply use a self-signed certificate.

SSL usespublic key cryptography, which is based onkey pairs. Key pairs contain one publickey and one private key. If data is encrypted with one key, itcan be decrypted only with the other key of the pair. This propertyis fundamental to establishing trust and privacy in transactions. For example, using SSL,the server computes a value and encrypts the value using its private key.The encrypted value is called adigital signature. The client decrypts the encrypted value usingthe server’s public key and compares the value to its own computed value.If the two values match, the client can trust that the signature isauthentic, because only the private key could have been used to produce sucha signature.

Digital certificates are used with the HTTPS protocol to authenticate web clients. TheHTTPS service of most web servers will not run unless a digital certificatehas been installed. Use the procedure outlined in the next section,Creating a Server Certificate, toset up a digital certificate that can be used by your application orweb server to enable SSL.

One tool that can be used to set up a digital certificate iskeytool, a key and certificate management utility that ships with the Java SESDK. It enables users to administer their own public/private key pairs and associatedcertificates for use in self-authentication (where the user authenticates himself or herself toother users or services) or data integrity and authentication services, using digital signatures. Italso allows users to cache the public keys (in the form of certificates)of their communicating peers. For a better understanding ofkeytool and publickey cryptography, read thekeytool documentation athttp://download.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html.

Creating a Server Certificate

A server certificate has already been created for the Application Server. The certificatecan be found in thedomain-dir/config/ directory. The server certificate is inkeystore.jks.Thecacerts.jks file contains all the trusted certificates, including client certificates.

If necessary, you can usekeytool to generate certificates. Thekeytool utility storesthe keys and certificates in a file termed akeystore, a repositoryof certificates used for identifying a client or a server. Typically, a keystoreis a file that contains one client or one server’s identity. It protectsprivate keys by using a password.

If you don’t specify a directory when specifying the keystore file name, thekeystores are created in the directory from which thekeytool command isrun. This can be the directory where the application resides, or it canbe a directory common to many applications.

To create a server certificate, follow these steps:

Create the keystore.
Export the certificate from the keystore.
Sign the certificate.
Import the certificate into atruststore: a repository of certificates used for verifying the certificates. A truststore typically contains more than one certificate.

Runkeytool to generate the server keystore,keystore.jks. This step uses thealiasserver-alias to generate a new public/private key pair and wrap the publickey into a self-signed certificate insidekeystore.jks. The key pair is generated using analgorithm of type RSA, with a default password ofchangeit. For more informationonkeytool options, see its online help athttp://download.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html.

Note -RSA is public-key encryption technology developed by RSA Data Security, Inc. The acronymstands for Rivest, Shamir, and Adelman, the inventors of the technology.

From the directory in which you want to create the keystore, runkeytool with the following parameters.

Generate the server certificate. (Type thekeytool command all on one line.)
```
java-home\bin\keytool -genkey -alias server-alias-keyalg RSA -keypass changeit -storepass changeit -keystore keystore.jks
```
When you press Enter,keytool prompts you to enter the server name, organizational unit, organization, locality, state, and country code.
You must enter the server name in response tokeytool’s first prompt, in which it asks for first and last names. For testing purposes, this can belocalhost.
When you run the example applications, the host specified in the keystore must match the host identified in thejavaee.server.name property specified in the filetut-install/javaeetutorial5/examples/bp-project/build.properties.
Export the generated server certificate inkeystore.jks into the fileserver.cer. (Type thekeytool all on one line.)
```
java-home\bin\keytool -export -alias server-alias -storepass changeit -file server.cer -keystore keystore.jks
```
If you want to have the certificate signed by a CA, readSigning Digital Certificates for more information.

To create the truststore filecacerts.jks and add the server certificate to the truststore, runkeytool from the directory where you created the keystore and server certificate. Use the following parameters:

java-home\bin\keytool -import -v -trustcacerts -alias server-alias -file server.cer -keystore cacerts.jks -keypass changeit -storepass changeit

Information on the certificate, such as that shown next, will display.

%keytool -import -v -trustcacerts -alias server-alias -file server.cer -keystore cacerts.jks -keypass changeit -storepass changeitOwner: CN=localhost, OU=Sun Micro, O=Docs, L=Santa Clara, ST=CA, C=USIssuer: CN=localhost, OU=Sun Micro, O=Docs, L=Santa Clara, ST=CA, C=USSerial number: 3e932169Valid from: Tue Apr 08Certificate 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:9A:3A:1C:17:4A:28:5E:97:20:78:3F:Trust this certificate? [no]:

Enteryes, and then press theEnter orReturn key. The following information displays:
```
Certificate was added to keystore[Saving cacerts.jks]
```

Signing Digital Certificates

After you’ve created a digital certificate, you will want to have it signedby its owner. After the digital certificate has been cryptographically signed by itsowner, it is difficult for anyone else to forge. For sites involved ine-commerce or any other business transaction in which authentication of identity is important,a certificate can be purchased from a well-known certificate authority such as VeriSignor Thawte.

As mentioned earlier, if authentication is not really a concern, you can savethe time and expense involved in obtaining a CA certificate and simply usethe self-signed certificate.

Obtaining a Digitally Signed Certificate

This example assumes that the keystore is namedkeystore.jks, the certificate file isserver.cer, and the CA file iscacerts.jks. To get your certificate digitallysigned by a CA:

Generate a Certificate Signing Request (CSR).

keytool -certreq -alias server-alias -keyalg RSA -filecsr-filename -keystore cacerts.jks

Send the contents of thecsr-filename for signing.
If you are using Verisign CA, go tohttp://digitalid.verisign.com/. Verisign will send the signed certificate in email. Store this certificate in a file.

Using a Different Server Certificate with the Application Server

Follow the steps inCreating a Server Certificate, to create your own server certificate, have itsigned by a CA, and import the certificate intokeystore.jks.

Make sure that when you create the certificate, you follow these rules:

When you create the server certificate,keytool prompts you to enter your first and last name. In response to this prompt, you must enter the name of your server. For testing purposes, this can belocalhost.
The server/host specified in the keystore must match the host identified in thejavaee.server.name property specified in thetut-install/javaeetutorial5/examples/bp-project/build.properties file for running the example applications.
Your key/certificate password inkeystore.jks should match the password of your keystore,keystore.jks. This is a bug. If there is a mismatch, the Java SDK cannot read the certificate and you get a “tampered” message.
If you want to replace the existingkeystore.jks, you must either change your keystore’s password to the default password (changeit) or change the default password to your keystore’s password.

To specify that the Application Server should use the new keystore forauthentication and authorization decisions, you must set the JVM options for the ApplicationServer so that they recognize the new keystore. To use a different keystorethan the one provided for development purposes, follow these steps.

Start the Application Server if you haven’t already done so. Information on starting the Application Server can be found inStarting and Stopping the Application Server.
Start the Admin Console. Information on starting the Admin Console can be found inStarting the Admin Console.
Select Application Server in the Admin Console tree.
Select the JVM Settings tab.
Select the JVM Options tab.

Change the following JVM options so that they point to the location and name of the new keystore. There current settings are shown below:

-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot}/config/keystore.jks -Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot}/config/cacerts.jks

If you’ve changed the keystore password from its default value, you need to add the password option as well:
```
-Djavax.net.ssl.keyStorePassword=your-new-password
```
Log out of the Admin Console and restart the Application Server.

Miscellaneous Commands for Certificates

To check the contents of a keystore that contains a certificate with analiasserver-alias, use this command:

keytool -list -keystore keystore.jks -alias server-alias -v

To check the contents of thecacerts file, use this command:

keytool -list -keystore cacerts.jks

Enabling Mutual Authentication over SSL

This section discusses setting up client-side authentication. When both server-side and client-side authenticationare enabled, it is called mutual, or two-way, authentication. In client authentication, clientsare required to submit certificates that are issued by a certificate authority thatyou choose to accept.

There are at least two ways to enable mutual authentication over SSL:

The preferred method is to set the method of authentication in theweb.xml application deployment descriptor toCLIENT-CERT. This enforces mutual authentication by modifying the deployment descriptor of the given application. By enabling client authentication in this way, client authentication is enabled only for a specific resource controlled by the security constraint, and the check is only performed when the application requires client authentication.
A less commonly used method is to set theclientAuth property in thecertificate realm totrue if you want the SSL stack to require a valid certificate chain from the client before accepting a connection. Afalse value (which is the default) will not require a certificate chain unless the client requests a resource protected by a security constraint that usesCLIENT-CERT authentication. When you enable client authentication by setting theclientAuth property totrue, client authentication will be required for all the requests going through the specified SSL port. If you turnclientAuth on, it is on all of the time, which can severely degrade performance.

When client authentication is enabled in both of these ways, client authentication willbe performed twice.

Creating a Client Certificate for Mutual Authentication

If you have a certificate signed by a trusted Certificate Authority (CA) suchas Verisign, and the Application Servercacerts.jks file already contains a certificate verifiedby that CA, you do not need to complete this step. You onlyneed to install your certificate in the Application Server certificate file when yourcertificate is self-signed.

From the directory where you want to create the client certificate, runkeytoolas outlined here. When you press Enter,keytool prompts you to enterthe server name, organizational unit, organization, locality, state, and country code.

You must enter theserver name in response tokeytool’s first prompt, inwhich it asks for first and last names. For testing purposes, this canbelocalhost. The host specified in the keystore must match the host identifiedin thejavee.server.host variable specified in yourtut-install/javaeetutorial5/examples/bp-project/build.properties file. If this exampleis to verify mutual authentication and you receive a runtime error stating thatthe HTTPS host name is wrong, re-create the client certificate, being sure touse the same host name that you will use when running the example.For example, if your machine name isduke, then enterduke as thecertificate CN or when prompted for first and last names. When accessing theapplication, enter a URL that points to the same location (for example,https://duke:8181/mutualauth/hello).This is necessary because during SSL handshake, the server verifies the client certificateby comparing the certificate name and the host name from which it originates.

To create a keystore namedclient_keystore.jks that contains a client certificate namedclient.cer,follow these steps:

Create a backup copy of the server truststore file. To do this,
1. Change to the directory containing the server’s keystore and truststore files,as-install\domains\domain1\config.
2. Copycacerts.jks tocacerts.backup.jks.
3. Copykeystore.jks tokeystore.backup.jks.
  Do not put client certificates in thecacerts.jks file. Any certificate you add to thecacerts file effectively means it can be a trusted root for any and all certificate chains. After you have completed development, delete the development version of thecacerts file and replace it with the original copy.
Generate the client certificate. Enter the following command from the directory where you want to generate the client certificate:
```
java-home\bin\keytool -genkey -alias client-alias -keyalg RSA -keypass changeit -storepass changeit -keystore client_keystore.jks
```

Export the generated client certificate into the fileclient.cer.

java-home\bin\keytool -export -alias client-alias -storepass changeit -file client.cer -keystore client_keystore.jks

Add the certificate to the truststore filedomain-dir/config/cacerts.jks. Runkeytool from the directory where you created the keystore and client certificate. Use the following parameters:

java-home\bin\keytool -import -v -trustcacerts -alias client-alias -file client.cer -keystoredomain-dir/config/cacerts.jks -keypass changeit -storepass changeit

Thekeytool utility returns a message like this one:

Owner: CN=localhost, OU=Java EE, O=Sun, L=Santa Clara, ST=CA, C=USIssuer: CN=localhost, OU=Java EE, O=Sun, L=Santa Clara, ST=CA, C=USSerial number: 3e39e66aValid from: Thu Jan 30 18:58:50 PST 2005 until: Wed Apr 3019:58:50 PDT 2005Certificate 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:32Trust this certificate? [no]: yesCertificate was added to keystore

Restart the Application Server.