Skip Headers
Oracle® Application Server Administrator's Guide
10g Release 2 (10.1.2)
  Go To Documentation Library
Go To Product List
Solution Area
Go To Table Of Contents
Go To Index


13 Overview of Secure Sockets Layer (SSL) in Oracle Application Server

In Oracle Application Server, components send requests to and receive responses from other components. These components can be Oracle Application Server components (such as OracleAS Single Sign-On, OracleAS Web Cache, or Oracle HTTP Server) or external clients such as browsers.

To secure these communications, you can configure Oracle Application Server to use SSL, which is an industry standard for securing communications. Oracle Application Server supports SSL versions 2 and 3, as well as TLS version 1.

This chapter provides an overview of SSL and how you can use it with Oracle Application Server. It contains the following topics:

13.1 What SSL Provides

SSL secures communication by providing message encryption, integrity, and authentication. The SSL standard allows the involved components (such as browsers and HTTP servers) to negotiate which encryption, authentication, and integrity mechanisms to use.

13.2 About Private and Public Key Cryptography

To provide message integrity, authentication, and encryption, SSL uses both private and public key cryptography.

Private Key Cryptography

Private, or symmetric, key cryptography requires a single, secret key shared by two or more parties to secure communication. This key is used to encrypt and decrypt secure messages sent between the parties. This requires prior and secure distribution of the key to each party. The problem with this method is that it is difficult to securely transmit and store the key.

In SSL, each party calculates the secret key individually using random values known to each side. The parties then send messages encrypted using the secret key.

Public Key Cryptography

Public key cryptography solves this problem by employing public and private key pairs and a secure method for key distribution. The freely available public key is used to encrypt messages that can only be decrypted by the holder of the associated private key. The private key is securely stored, together with other security credentials, in an encrypted container such as an Oracle wallet.

Public key algorithms can guarantee the secrecy of a message, but they do not necessarily guarantee secure communication because they do not verify the identities of the communicating parties. To establish secure communication, it is important to verify that the public key used to encrypt a message does in fact belong to the target recipient. Otherwise, a third party can potentially eavesdrop on the communication and intercept public key requests, substituting its own public key for a legitimate key (the man-in-the-middle attack).

To avoid such an attack, it is necessary to verify the owner of the public key, a process called authentication. Authentication can be accomplished through a certificate authority (CA), which is a third party trusted by both of the communicating parties.

The CA issues public key certificates that contain an entity's name, public key, and certain other security credentials. Such credentials typically include the CA name, the CA signature, and the certificate effective dates (From Date, To Date).

The CA uses its private key to encrypt a message, while the public key is used to decrypt it, thus verifying that the message was encrypted by the CA. The CA public key is well known, and does not have to be authenticated each time it is accessed. Such CA public keys are stored in wallets.

13.3 How an SSL Session Is Set Up (the "SSL Handshake")

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 13-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 using the server's certificate.

  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 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.

Figure 13-1 SSL Handshake

Description of Figure 13-1 follows
Description of "Figure 13-1 SSL Handshake"

13.4 Requirements for Using SSL in Oracle Application Server

To use SSL in Oracle Application Server:

The following sections in this chapter describe these topics in more detail.

13.5 Certificates and Oracle Wallets

You need a certificate for your site. When clients connect to your site requesting SSL communication, you usually have to send your certificate to them so that they can authenticate you.

Oracle Application Server supports X.509 V3 certificates, and certificates that conform to the PKIX standard (RFC 3280).

13.5.1 How to Get a Certificate

You get certificates from certificate authorities (CAs). CAs are trusted entities who sign the certificates that they issue with their private key. Clients can verify the issuer of a certificate (by using the CA's public key). Examples of CAs include Verisign ( and Thawte (

Oracle Application Server also has a certificate authority, called OracleAS Certificate Authority (OCA). You can use it to set up your own certificate authority. See the Oracle Application Server Certificate Authority Administrator's Guide for details.

To get a certificate, you submit a certificate request to a CA. The certificate request contains your information including your public key. You can use tools to generate a certificate request; these tools can generate private and public key pairs for you. Examples of tools that can generate certificate requests include Oracle Wallet Manager and Sun's keytool (for OC4J only). For information on Oracle Wallet Manager, see Chapter 15, "Managing Wallets and Certificates".

Among other items, a certificate includes the following pieces of data:

  • Certificate owner's name

  • Certificate owner's public key

  • CA's name

  • Certificate expiration date

  • Certificate serial number

Certificates are valid until they expire or until they are revoked.

Note that if you use OracleAS Certificate Authority (OCA) to create certificates for your server, most browsers will not accept these certificates without input from the browser user. This is because most browsers are preconfigured to accept certificates from certain CAs, and OCA is not one of them. The browser will reject the certificate from the server unless the user chooses to accept certificates from the server or import the CA's certificate.

This problem exists for all CAs until the CA's certificate is imported into the browsers. For more information, see the Oracle Application Server Certificate Authority Administrator's Guide.

13.5.2 Oracle Wallet

An Oracle wallet is a container that stores your credentials, such as 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 are password-protected.

You manage Oracle wallets using Oracle Wallet Manager. Use Oracle Wallet Manager to perform tasks such as creating Oracle wallets, creating certificate requests, importing certificates into the wallet, and uploading wallets to an LDAP directory.

Oracle Wallet Manager supports PKCS #11 and PKCS #12 wallets:

  • Scenario 1: You generate a certificate request using Oracle Wallet Manager and decide to store the private key on the file system. When you get your certificate from the CA, you can import it into an Oracle wallet. This wallet uses the PKCS #12 format. See Section, "Creating a Standard Wallet" for details.

  • Scenario 2: You generate a certificate request using Oracle Wallet Manager and decide to store the private key on a hardware security module. When you get your certificate from the CA, you can import it into an Oracle wallet. This wallet uses the PKCS #11 format. See Section, "Creating a Wallet to Store Hardware Security Module Credentials" for details.

  • Scenario 3: You already have a certificate in a wallet that uses the PKCS #12 format, and you want to use it with Oracle Application Server. The wallet was created using a third-party tool. In this case, use the tool that was used to create the wallet and export the wallet to a file on the file system. You can then import the wallet. See Section, "Importing Certificates Created with a Third-Party Tool" for details.

Components that Use Oracle Wallets

Oracle Application Server components that act as SSL servers need Oracle wallets (the wallet already contains the certificate that you want the server to use). Examples of these components include Oracle HTTP Server, OracleAS Web Cache, OPMN, Oracle Internet Directory, and the Port Tunneling daemon (iaspt).

You configure the component with the location of the Oracle wallet. For example, to configure Oracle HTTP Server for SSL, you specify the location of the wallet using the SSLWallet directive. Refer to the component guide for specific instructions on how to specify the wallet location for the component.


The OC4J component uses a keystore instead of an Oracle wallet to store its certificate. You use a tool called keytool to import certificates into keystores. See the Oracle Application Server Containers for J2EE Security Guide for details on keystores and keytool.

13.5.3 Client Certificates

If you need to authenticate your clients, you can configure the Oracle HTTP Server to require clients to send their certificates. Clients can also get their certificates from CAs.

If the clients are Oracle components, for example, OracleAS Web Cache can act as a client when communicating with Oracle HTTP Server, the client component can store its certificate in an Oracle wallet. OPMN also acts as a client when configured for SSL.

If the client is a browser, the client does not need an Oracle wallet. You can just import the certificate into the browser.

Other types of clients, such as SOAP or Web Services clients, have their own ways of configuring certificates and certificate stores.

13.6 SSL Configuration Overview

You enable components in Oracle Application Server to use SSL using the Application Server Control. In some cases, you edit configuration files by hand.

SSL secures communication between two parties: a client and a server. If three or more parties are involved, for example, client browser, OracleAS Web Cache, Oracle HTTP Server, and OC4J, then you may have to configure all components to use SSL.

Figure 13-2 shows typical communication paths between Oracle Application Server components and the protocols that they use. For example, browsers use HTTP to communicate with OracleAS Web Cache, and Oracle HTTP Server uses AJP to communicate with OC4J. All these protocols can work with SSL.

Figure 13-2 Communication Paths Between Components in Oracle Application Server

Communication Paths among Components in Application Server
Description of "Figure 13-2 Communication Paths Between Components in Oracle Application Server"

13.6.1 Default SSL Configuration

If you select the default options in the Oracle Application Server installation, none of the components are configured for SSL.

On installation screens where you specify the Oracle Internet Directory host and port, there is an option marked "Use only SSL connections with this Oracle Internet Directory." If you select this option, you need to provide Oracle Internet Directory's SSL port number, and the installer configures the components to use SSL only to communicate with Oracle Internet Directory during runtime.

13.6.2 Partial SSL Configuration

Oracle Application Server enables you to configure SSL for only the paths you want to secure. There are many paths used by components, as shown in Figure 13-2.

You might not want to secure all paths for the following reasons:

  • SSL is resource-intensive. If you have heavy SSL traffic, then you probably need to offload SSL processing to an SSL accelerator. See Section 13.7, "Integration with Hardware Security Modules" for details.

  • If your computers are behind firewalls, you might need to secure only paths that are accessed by the public. For example, you might need to secure only OracleAS Web Cache and Oracle HTTP Server if the public can access only these components.

13.7 Integration with Hardware Security Modules

When clients connect to your site using SSL, the extra processing required for SSL strains your servers, and your site as a whole (SSL as well as non-SSL connections) will experience slower performance and throughput. You should consider using SSL accelerator hardware to offload SSL computations and improve performance.

Types of SSL accelerators:

13.7.1 Protocol Converters

Protocol converters convert HTTPS traffic to HTTP. Protocol converters are standalone hardware machines. Oracle Application Server supports protocol converters from companies such as:


SSL connections to protocol converters terminate at the protocol converter. When the converters forward the requests to Oracle Application Server, most of them do so in an unencrypted fashion.

For the protocol converters that forward the requests to Oracle Application Server using SSL, this is still faster than not using a protocol converter because using a protocol converter eliminates most SSL key exchanges (which is the expensive operation).

13.7.2 Mathematics Accelerators (PKCS #11 Integration)

Mathematics accelerators improve the speed of math operations used by SSL. Such devices are usually plugged into a server (often through TCP/IP). Such devices often have additional features such as key management and secure key stores.

Oracle Application Server supports mathematics accelerators that follow the PKCS #11 standard. For a list of certified accelerators, you can check the OracleMetaLink site,