background image

Verifying SSL Support

<< Specifying a Secure Connection | Working with Digital Certificates >>
<< Specifying a Secure Connection | Working with Digital Certificates >>

Verifying SSL Support

mechanism can alleviate this concern. Configuring a user authentication mechanism is
described in
"Specifying an Authentication Mechanism" on page 858
.
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
Establishing a Secure Connection Using SSL
Chapter 28 · Introduction to Security in the Java EE Platform
787