Establishing a Secure Connection Using SSL

Secure Socket Layer (SSL) technology is security
that is implemented at the transport layer (see Transport-Layer Security, for more information about transport layer security). SSL
allows web browsers and web servers to communicate over a secure connection.
In this secure connection, the data that is being sent is encrypted before
being sent and then is decrypted upon receipt and before processing. Both
the browser and the server encrypt all 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.

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

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

There must be a Connector 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.

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

A user data constraint (<user-data-constraint> in
the deployment descriptor) requires that all constrained URL patterns and
HTTP methods specified in the security constraint are received over a protected
transport layer connection such as HTTPS (HTTP over SSL). A user data constraint
specifies a transport guarantee (<transport-guarantee> in
the deployment descriptor). The choices for transport guarantee include CONFIDENTIAL, INTEGRAL, or NONE.
If you specify CONFIDENTIAL or INTEGRAL as
a security constraint, that type of security constraint applies to all requests
that match the URL patterns in the web resource collection and not just to
the login dialog box.

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

Specify CONFIDENTIAL when the application
requires that data be transmitted so as to prevent other entities from observing
the contents of the transmission.

Specify INTEGRAL when the application requires
that the data be sent between client and server in such a way that it cannot
be changed in transit.

Specify NONE 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-based user
authentication. When the login authentication method is set to BASIC or FORM, passwords are not protected, meaning that passwords sent between
a client and a server on an unprotected session can be viewed and intercepted
by third parties. Using a user data constraint with the user authentication
mechanism can alleviate this concern.

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 port defined in the server deployment descriptor:

https://localhost:8181/

The https in this URL indicates that the browser
should be using the SSL protocol. The localhost in this
example assumes that you are running the example on your local machine as
part of the development process. The 8181 in this example
is the secure port that was specified where the SSL connector was created.
If you are using a different server or port, modify this value accordingly.

The first time that you load this application, the New Site Certificate
or Security Alert dialog box displays. Select Next to move through the series
of dialog boxes, and select Finish when you reach the last dialog box. The
certificates will display only the first time. When you accept the certificates,
subsequent hits 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 is not strictly necessary to run an entire
web application over SSL, and it is customary for a developer to decide which
pages require a secure connection and which do not. Pages that might require
a secure connection include login pages, personal information pages, shopping
cart checkouts, or any pages where credit card information could possibly
be transmitted. Any page within an application can be requested over a secure
socket by simply prefixing the address with https: instead
of http:. Any pages that absolutely require a secure connection
should check the protocol type associated with the page request and take the
appropriate action if https is not specified.

Using name-based virtual hosts on a secured connection can be problematic.
This is a design limitation of the SSL protocol itself. The SSL handshake, where the client browser accepts the server certificate, must
occur before the HTTP request is accessed. As a result, the request information
containing the virtual host name cannot be determined before authentication,
and it is therefore not possible to assign multiple certificates to a single
IP address. If all virtual hosts on a single IP address need to authenticate
against the same certificate, the addition of multiple 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 name against
the domain name listed in the certificate, if any (this is applicable primarily
to official, CA-signed certificates). If the domain names do not match, these
browsers will display a warning to the client. In general, only address-based
virtual hosts are commonly used with SSL in a production environment.

Working with Digital Certificates

Digital certificates for the Enterprise Server have already been generated
and can be found in the directory as-install/domain-dir/config/.
These digital certificates are self-signed and are intended for use in a development
environment; they are not intended for production purposes. For production
purposes, generate your own certificates and have them signed by a CA.

The instructions in this section apply to the developer and cluster
profiles of the Enterprise Server. In the enterprise profile, the certutil utility
is used to create digital certificates. For more information, see the Sun GlassFish Enterprise Server v3 Administration Guide.

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

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

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

SSL uses public key cryptography, which is
based on key pairs. Key pairs contain one public key
and one private key. If data is encrypted with one key, it can be decrypted
only with the other key of the pair. This property is 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 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 the two values match, the client can trust that
the signature is authentic, because only the private key could have been used
to produce such a signature.

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

One tool that can be used to set
up a digital certificate is keytool, a key and certificate
management utility that ships with the Java SE SDK. It enables users to administer
their own public/private key pairs and associated certificates for use in
self-authentication (where the user authenticates himself or herself to other
users or services) or data integrity and authentication services, using digital
signatures. It also allows users to cache the public keys (in the form of
certificates) of their communicating peers. For a better understanding of keytool and public key cryptography, read the keytool documentation
at http://java.sun.com/javase/6/docs/technotes/tools/solaris/keytool.html.

Creating a Server Certificate

A server certificate has already been created for the Enterprise Server.
The certificate can be found in the domain-dir/config/ directory.
The server certificate is in keystore.jks. The cacerts.jks file contains all the trusted certificates, including client certificates.

If necessary, you
can use keytool to generate certificates. The keytool utility stores the keys and certificates in a file termed a keystore, a repository of certificates used for identifying a client
or a server. Typically, a keystore is a file that contains one client or one
server’s identity. It protects private keys by using a password.

If you don’t specify a directory when specifying the keystore
file name, the keystores are created in the directory from which the keytool command is run. This can be the directory where the application
resides, or it can be 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 a truststore:
a repository of certificates used for verifying the certificates. A truststore
typically contains more than one certificate.

Run keytool to generatea new key pair in the default
development keystore file, keystore.jks. This example
uses the alias server-alias to generate a new public/private
key pair and wrap the public key into a self-signed certificate inside keystore.jks. The key pair is generated using an algorithm of type
RSA, with a default password of changeit. For more information
and other examples of creating and managing keystore files, read the keytool online help at http://java.sun.com/javase/6/docs/technotes/tools/solaris/keytool.html.

Note –

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

From the directory in which you want to create the key pair , run keytool with the following parameters.

Generate the server certificate. (Type the keytool command
all on one line.)

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 to keytool’s
first prompt, in which it asks for first and last names. For testing purposes,
this can be localhost.

When you run the example applications, the host (server name) specified
in the keystore must match the host identified in the javaee.server.name property specified in the file tut-install/examples/bp-project/build.properties.

Export the generated server certificate in keystore.jks into the file server.cer. (Type the keytool command all on one line.)