SSL

How SSL Sessions Are Conducted

The SSL protocol has two phases: the handshake phase and the data transfer phase.

The handshake phase authenticates the server and optionally the client, and
establishes the cryptographic keys that will be used to protect the data to be
transmitted in the data transfer phase.
When a client requests an SSL connection to a server, the client and server first
exchange messages in the handshake phase. (A common scenario is a browser
requesting a page using the https:// instead of http:// protocol from a server. The
HTTPS protocol indicates the usage of SSL with HTTP.)
Figure 6–1 shows the handshake messages for a typical SSL connection between a Web
server and a browser. The following steps are shown in the figure:
1. The client sends a Hello message to the server.
The message includes a list of algorithms supported by the client and a random
number that will be used to generate the keys.
2. The server responds by sending a Hello message to the client. This message
includes:
■ The algorithm to use. The server selected this from the list sent by the client.
■ A random number, which will be used to generate the keys.
3. The server sends its certificate to the client.
4. The client authenticates the server by checking the validity of the server's
certificate, the issuer CA, and optionally, by checking that the host name of the
server matches the subject DN. The client sends a Session ID for session caching.
5. The client generates a random value ("pre-master secret"), encrypts it using the
server's public key, and sends it to the server.
6. The server uses its private key to decrypt the message to retrieve the pre-master
secret.
7. The client and server separately calculate the keys that will be used in the SSL
session.
These keys are not sent to each other because the keys are calculated based on the
pre-master secret and the random numbers, which are known to each side. The
keys include:
■ Encryption key that the client uses to encrypt data before sending it to the
server
■ Encryption key that the server uses to encrypt data before sending it to the
client
■ Key that the client uses to create a message digest of the data
■ Key that the server uses to create a message digest of the data
The encryption keys are symmetric, that is, the same key is used to encrypt and
decrypt the data.
8. The client and server send a Finished message to each other. These are the first
messages that are sent using the keys generated in the previous step (the first
"secure" messages).
The Finished message includes all the previous handshake messages that each
side sent. Each side verifies that the previous messages that it received match the
About SSL in Oracle Fusion Middleware
Configuring SSL in Oracle Fusion Middleware 6-5
messages included in the Finished message. This checks that the handshake
messages were not tampered with.
9. The client and server now transfer data using the encryption and hashing keys
and algorithms.

Authentication Modes

The following authentication modes are supported:
■ In no-authentication mode, neither server nor client are required to authenticate.
Other names for this mode include Anonymous SSL/No
Authentication/Diffie-Hellman. This mode is considered unsecured.
■ In server authentication mode, a server authenticates itself to a client.
This mode is also referred to as One-way SSL/Server Authentication.
■ In mutual authentication mode, a client authenticates itself to a server and that server
authenticates itself to the client.
This mode is also known as Two-way SSL/Client Authentication.
■ In optional client authentication mode, the server authenticates itself to the client, but
the client may or may not authenticate itself to the server. Even if the client does
not authenticate itself, the SSL session still goes through.

 

Key and Certificate Storage in Oracle Fusion Middleware

Private keys, digital certificates, and trusted CA certificates are stored in keystores.

A JKS keystore is the default JDK implementation of Java keystores provided by Sun
Microsystems. In 11g Release 1 (11.1.1), all Java components and Java EE applications
use the JKS-based keystore and truststore.

In Oracle Fusion Middleware, you can use graphical user interface or command-line
tools to create, import, export, and delete a Java keystore and the certificates contained
in the keystore

While creating a keystore, you can pre-populate it with akeypair wrapped in a
self-signed certificate; such a keystore is typically used in development and testing
phases.（Certificate）
The other choice is to generate a certificate signing requestfor a keypair, so that you
can request a signed certificate back from a Certificate Authority (CA). Once the CA
sends the certificate back, it is imported into the keystore; the keystore now contains a
trusted certificate, since it comes from a trusted third-party. Such a keystore is typically
used in production environments.（Trusted Certificate）
Keystores are always password-protected.

A Java keystore (JKS) is a protected database that holds keys and certificates for the
organization. Oracle Fusion Middleware utilizes JKS keystores for Oracle Virtual
Directory, for applications deployed in Oracle WebLogic Server, and for Oracle
WebLogic Server itself.
Access to a keystore requires a password which is defined at the time the keystore is
created, by the person who creates the keystore, and which can only be changed by
providing the current password.
In addition, each private key in a keystore can be secured by its own password.

 

An Oracle wallet is a container that stores your credentials, such as certificates, trusted
certificates, certificate requests, and private keys. You can store Oracle wallets on the
file system or in LDAP directories such as Oracle Internet Directory. Oracle wallets can
be auto-login or password-protected wallets.

You use an Oracle Wallet for the following components:
■ Oracle HTTP Server
■ Oracle Web Cache
■ Oracle Internet Directory

Keystore Management Tools

Oracle Fusion Middleware provides these options for keystore operations:
■ WLST, a command-line interface for JKS keystores and wallets
■ orapki, a command-line tool for wallets
■ Fusion Middleware Control, a graphical user interface
■ Oracle Wallet Manager, a stand-alone graphical user interface for wallets,
recommended for managing PKCS#11 wallets.