Configuring SSL in Oracle Fusion Middleware

6 Configuring SSL in Oracle Fusion Middleware

Secure Sockets Layer (SSL) is used to secure communications between Oracle Fusion Middleware components in web, middle, and data tiers. This chapter provides procedures to secure communications, describes advanced scenarios beyond the basic topologies and explains best practices.

Note:

The term "SSL" is used generically in this document to denote secure transport mechanisms including Transport Layer Security (TLS).

Refer to component-specific documentation to learn about the cipher suite(s) that the client can use during the SSL/TLS handshake.

Note:

Where SSL connections are configured within Oracle WebLogic Server, this chapter provides references to the relevant component documentation rather than duplicating the instructions here.

How SSL Works
Secure Sockets Layer (SSL) provides a secured communication between two entities, that is, a client and a server over an unsecured network. The SSL communication is achieved by using a set of protocols in both the handshake and data transfer phases. You can also review the basic concepts of SSL, cryptography in general, Oracle Wallet and keystore.
About SSL in Oracle Fusion Middleware
You can review the keystores and wallets that are central to SSL communication and other features like TLS cryptographic libraries that Oracle Fusion Middleware support.
Configuring SSL for Configuration Tools
Several tools are available for Oracle Fusion Middleware configuration. These tools must be configured with SSL to enable them to connect to an SSL-enabled Oracle WebLogic Server.
Configuring SSL for the Web Tier
Oracle HTTP Server resides in the web tier of the Oracle Fusion Middleware. It secures communications by using a SSL protocol.
Configuring SSL for the Middle Tier
SSL in the middle tier of the Oracle Fusion Middleware includes enabling SSL for the application server and also the components and applications running on the application server.
Configuring SSL for the Data Tier
The data tier of the Oracle Fusion Middleware includes Oracle Database as a component. All components in the data tier must be SSL enabled.
Setting Up One-Way SSL to the LDAP Security Store
Follow these steps to set up a one-way Secure Sockets Layer (SSL) channel between Oracle WebLogic Server or a Java SE application, and the LDAP security store. Such connection may be required, for example, when reassociating to an LDAP target store.
Setting Up SSL in Identity Store Services
Establishing SSL connections in Identity Store Services using libOVD and JKS requires keystore certificates that are kept in multiple locations, such as the WebLogic Server truststore and the adapters.jks file.
Advanced SSL Scenarios
SSL configuration in Oracle Fusion Middleware also includes additional scenarios that are beyond the basic topologies like FIPS 140 support, Hardware Security Modules and certificate validation.
Best Practices for SSL
Oracle Fusion Middleware recommends some best practices for component administrators and application developers while configuring SSL.
WLST Reference for SSL
WLST commands are available to manage Oracle wallets and to configure SSL for Oracle Fusion Middleware components.

Parent topic: Secure Communication

How SSL Works

Secure Sockets Layer (SSL) provides a secured communication between two entities, that is, a client and a server over an unsecured network. The SSL communication is achieved by using a set of protocols in both the handshake and data transfer phases. You can also review the basic concepts of SSL, cryptography in general, Oracle Wallet and keystore.

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.
About Private and Public Key Cryptography
SSL uses both private and public key cryptography to provide message integrity, authentication, and encryption.
Keystores and Wallets
In Oracle Fusion Middleware, components such as Oracle HTTP Server use the Oracle Wallet as their storage mechanism. An Oracle wallet is a container that stores your credentials, such as certificates, trusted certificates, certificate requests, and private keys.
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.

Parent topic: Configuring SSL in Oracle Fusion Middleware

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.

Encryption provides confidentiality by allowing only the intended recipient to read the message. SSL can use different encryption algorithms to encrypt messages. During the SSL handshake that occurs at the start of each SSL session, the client and the server negotiate which algorithm to use. Examples of encryption algorithms supported by SSL include AES, RC4, and 3DES.

Integrity ensures that a message sent by a client is received intact by the server, untampered. To ensure message integrity, the client hashes the message into a digest using a hash function and sends this message digest to the server. The server also hashes the message into a digest and compares the digests. Because SSL uses hash functions that make it computationally infeasible to produce the same digest from two different messages, the server can tell that if the digests do not match, someone had tampered with the message. An example of a hash function supported by SSL is SHA2.

Authentication enables the server and client to check that the other party is who it claims to be. When a client initiates an SSL session, the server typically sends its certificate to the client. Certificates are digital identities that are issued by trusted certificate authorities, such as Verisign. Managing Keystores, Wallets, and Certificates describes certificates in more detail.

The client verifies that the server is authentic and not an imposter by validating the certificate chain in the server certificate. The server certificate is guaranteed by the certificate authority (CA) who signed the server certificate.

The server can also require the client to have a certificate, if the server needs to authenticate the identity of the client.

Parent topic: How SSL Works

About Private and Public Key Cryptography

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

Secret Key Cryptography

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. It 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 encrypted messages 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. Together with other security credentials, private key is securely stored in an encrypted container such as an Oracle wallet.

Public key algorithms can guarantee the secrecy of a message. However, 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 with a process called authentication. trusted by both of the communicating parties, a third party known as a certificate authority (CA) can accomplish the authentication process.

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.

Parent topic: How SSL Works

Keystores and Wallets

In Oracle Fusion Middleware, components such as Oracle HTTP Server use the Oracle Wallet as their storage mechanism. 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.

Oracle HTTP Server uses Oracle wallet. Configuring SSL for Oracle HTTP Server thus requires setting up and using Oracle wallets.

Note:

As of Oracle Fusion Middleware 12c (12.1.3), you can take advantage of the central storage and unified management available with the Keystore Service to manage wallets and their contents through the export, import, and synchronization features of that service. For details about the importKeyStore, exportKeyStore, and syncKeyStore commands, see “Infrastructure Security Custom WLST Commands” in the WLST Command Reference for Infrastructure Security.

Other components use a JKS keystore or KSS keystore to store keys and certificates, and configuring SSL for these components requires setting up and using the appropriate keystores.

For more information about configuring keystores and wallets, see:

About SSL in Oracle Fusion Middleware for a fuller description of keystore and wallet usage in Oracle Fusion Middleware
Managing Keystores, Wallets, and Certificates for a discussion of these terms, and administration details

Parent topic: How SSL Works

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:

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.
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.
The server sends its certificate to the client.
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.
The client generates a random value ("pre-master secret"), encrypts it using the server's public key, and sends it to the server.
The server uses its private key to decrypt the message to retrieve the pre-master secret.
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.
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.
The client and server now transfer data using the encryption and hashing keys and algorithms.

Figure 6-1 SSL Handshake

Description of "Figure 6-1 SSL Handshake"

Parent topic: How SSL Works

About SSL in Oracle Fusion Middleware

You can review the keystores and wallets that are central to SSL communication and other features like TLS cryptographic libraries that Oracle Fusion Middleware support.

This section introduces SSL in Oracle Fusion Middleware. It contains these topics:

SSL in the Oracle Fusion Middleware Architecture
Review this topic for the role of SSL communication among the various components of the Oracle Fusion Middleware in its architecture.
Keystores and Oracle Wallets
Oracle Fusion Middleware 12c (12.2.1.1) supports different types of keystores for keys and certificates.
TLS Protocol Support in Oracle Fusion Middleware
Oracle Fusion Middleware supports TLS v1.2 cryptographic libraries. However, you will need to configure this protocol in the component since the library may not be enabled by default.
Authentication Modes in Oracle Fusion Middleware
Review this topic for the different modes of authentication that are supported between a client and a server in Oracle Fusion Middleware.
Tools for SSL Configuration
Oracle Fusion Middleware uses two kinds of configuration tools, common and advanced.

Parent topic: Configuring SSL in Oracle Fusion Middleware

SSL in the Oracle Fusion Middleware Architecture

Review this topic for the role of SSL communication among the various components of the Oracle Fusion Middleware in its architecture.

Figure 6-2 SSL in Oracle Fusion Middleware

Description of "Figure 6-2 SSL in Oracle Fusion Middleware"

Note:

In Figure 6-2, the label "Oracle Enterprise Manager" refers to the Fusion Middleware Control user interface.
Other administrative tools are available for specific tasks.

In the Oracle Fusion Middleware architecture shown in Figure 6-2, the circles represent the endpoints that can be SSL-enabled. For configuration details about each endpoint, see:

Enabling SSL for Inbound Requests to Oracle HTTP Server Virtual Hosts Using Fusion Middleware Control and Enabling SSL for Inbound Requests to Oracle HTTP Server Virtual Hosts Using WLST
Enabling SSL for Outbound Requests from Oracle HTTP Server
Configuring Inbound SSL to Oracle WebLogic Server
Outbound connections to the LDAP server can originate from Oracle Platform Security Services or from Oracle WebLogic Server:
1. Configuring Outbound SSL from Oracle Platform Security Services to LDAP
2. Configuring Outbound SSL from LDAP Authenticator to LDAP
SSL-Enabling a Data Source
SSL-Enabling Oracle Database
Client-Side SSL for Applications
Configuring Outbound SSL from Oracle WebLogic Server
SSL-Enabling Oracle Database

Keystores and Wallets

Keystores and wallets are central to SSL configuration and are used to store certificates and keys.

For details, see Keystores and Oracle Wallets.

Parent topic: About SSL in Oracle Fusion Middleware

Keystores and Oracle Wallets

Oracle Fusion Middleware 12c (12.2.1.1) supports different types of keystores for keys and certificates.

JKS-based keystore and truststore

Oracle WebLogic Server uses JKS keystores in upgraded environments.

JDK's keytool utility manages JKS keystores and certificates.
Oracle wallet

System components like Oracle HTTP Server use the Oracle wallet.

Use Fusion Middleware Control, or the command-line WLST and orapki interfaces, to manage wallets and their certificates for system components. You can use either the Fusion Middleware Control or WLST to SSL-enable the listeners for these components.
OPSS Keystore Service (KSS) keystore and truststore

The Keystore Service provides an alternative mechanism to manage keys and certificates. Oracle WebLogic Server uses KSS keystores out-of-the-box in new 12c (12.2.1.1) installations.

Use Fusion Middleware Control or WLST to manage KSS keystores and their certificates. Use the WebLogic console to SSL-enable the listeners for WebLogic servers.

For more information about these types of stores, and when to use which type of store, see Keystores and Wallets.

See Also:

Key and Certificate Storage in Oracle Fusion Middleware for keystore management

JDK8 Requires keyUsage with keyCertSign

Under JDK8, self-signed CA certificates used for SSL configuration must have the keyUsage extension with keyCertSign asserted. For details, see keyUsage Extension Required for Certificates in JDK8.

Parent topic: About SSL in Oracle Fusion Middleware

TLS Protocol Support in Oracle Fusion Middleware

Oracle Fusion Middleware supports TLS v1.2 cryptographic libraries. However, you will need to configure this protocol in the component since the library may not be enabled by default.

Table provides links to the relevant procedures:

Table 6-1 TLS v1.2 Support in Oracle Fusion Middleware Components

Component/Feature	TLS Documentation
Oracle HTTP Server	"SSLProtocol" in Administering Oracle HTTP Server
Oracle WebLogic Server	"Specifying the SSL Protocol Version" in Administering Security for Oracle WebLogic Server
Oracle Traffic Director	"Managing Security" in Oracle® Fusion Middleware Administering Oracle Traffic Director "SSL Management"in WebLogic Scripting Tool Command Reference for Oracle Traffic Director

Component/Feature

TLS Documentation

Oracle HTTP Server

"SSLProtocol" in Administering Oracle HTTP Server

Oracle WebLogic Server

"Specifying the SSL Protocol Version" in Administering Security for Oracle WebLogic Server

Oracle Traffic Director

"Managing Security" in Oracle® Fusion Middleware Administering Oracle Traffic Director

"SSL Management"in WebLogic Scripting Tool Command Reference for Oracle Traffic Director

Parent topic: About SSL in Oracle Fusion Middleware

Authentication Modes in Oracle Fusion Middleware

Review this topic for the different modes of authentication that are supported between a client and a server in Oracle Fusion Middleware.

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.

Parent topic: About SSL in Oracle Fusion Middleware

Tools for SSL Configuration

Oracle Fusion Middleware uses two kinds of configuration tools, common and advanced.

Common Tools

Fusion Middleware Control
WLST command-line interface
Oracle WebLogic Server Administration Console
keytool command-line tool

These tools allow you to configure SSL and manage Oracle Wallet/JKS keystore for any listener or component in Oracle Fusion Middleware.

The first three tools on this list are usable when the component is associated with the application server domain (when the component is not a stand-alone installation).

Advanced Tools

orapki command-line tool is needed to manage wallets for certain stand-alone installations.

See Also:

Key and Certificate Storage in Oracle Fusion Middleware for keystore management.

Parent topic: About SSL in Oracle Fusion Middleware

Configuring SSL for Configuration Tools

Several tools are available for Oracle Fusion Middleware configuration. These tools must be configured with SSL to enable them to connect to an SSL-enabled Oracle WebLogic Server.

See Also:

Configuring Inbound SSL to Oracle WebLogic Server for details about enabling inbound SSL on Oracle WebLogic Server.

For a list of all the configuration tools, see Tools for SSL Configuration.

This section contains these topics:

Oracle Enterprise Manager Fusion Middleware Control
Follow these steps to launch the Oracle Fusion Middleware Control or Enterprise Manager.
Oracle WebLogic Server Administration Console
Follow these steps to launch the Oracle WebLogic Server Administration Console.
WLST Command-Line Tool
Follow these steps to launch WLST for configuring SSL.
orapki Utility
orapki is the recommended tool to configure wallets.

Parent topic: Configuring SSL in Oracle Fusion Middleware

Oracle Enterprise Manager Fusion Middleware Control

Follow these steps to launch the Oracle Fusion Middleware Control or Enterprise Manager.

Ensure that the SSL port is enabled on the Oracle WebLogic Server instance on which Fusion Middleware Control is deployed, and that the browser (from which you will launch Fusion Middleware Control) trusts the server certificate.

For details, see “Configure server SSL settings in Administering Oracle WebLogic Server with Fusion Middleware Control.
Now launch Fusion Middleware Control using an SSL-based URL, in the format https://host:port.

Parent topic: Configuring SSL for Configuration Tools

Oracle WebLogic Server Administration Console

Follow these steps to launch the Oracle WebLogic Server Administration Console.

Ensure that the SSL port is enabled on the Oracle WebLogic Server instance. Now launch the administration console by providing the SSL port in the URL. You may get a warning that the certificate is not trusted; accept this certificate and continue.

For details, see “Configure server SSL settings” in Administering Oracle WebLogic Server with Fusion Middleware Control.

Parent topic: Configuring SSL for Configuration Tools

WLST Command-Line Tool

Follow these steps to launch WLST for configuring SSL.

Launch the WLST shell.
Execute the WLST command:
```
help('connect')
```

Follow the instructions described in the help text to set up the WLST shell in SSL mode.

See Also:

WLST Reference for SSL for details about using WLST.

Parent topic: Configuring SSL for Configuration Tools

orapki Utility

orapki is the recommended tool to configure wallets.

For details, see orapki.

Parent topic: Configuring SSL for Configuration Tools

Configuring SSL for the Web Tier

Oracle HTTP Server resides in the web tier of the Oracle Fusion Middleware. It secures communications by using a SSL protocol.

Note:

This discussion applies to the Web Tier in the context of an Oracle WebLogic Server domain.
The order in which these topics appear should not be confused with the sequence in which SSL is enabled (which varies depending on topology). Rather, they are arranged in order starting with the most front-ending component.

This chapter does not cover all Oracle HTTP Server configuration options. For additional scenarios, see “OHS in a WebLogic Server Domain” and “OHS in a Standalone Domain” in Installing and Configuring Oracle HTTP Server.

This section describes SSL for Oracle HTTP Server which resides in the Web tier, and contains these topics:

Configuring Load Balancers
Use the instructions specific to your load-balancing device to configure load balancers in your Oracle Fusion Middleware environment.
Enabling SSL for Oracle HTTP Server Virtual Hosts
Find out how to manage SSL configuration for Oracle HTTP Server virtual hosts operating in an Oracle WebLogic Server environment.

Parent topic: Configuring SSL in Oracle Fusion Middleware

Configuring Load Balancers

Use the instructions specific to your load-balancing device to configure load balancers in your Oracle Fusion Middleware environment.

Parent topic: Configuring SSL for the Web Tier

Enabling SSL for Oracle HTTP Server Virtual Hosts

Find out how to manage SSL configuration for Oracle HTTP Server virtual hosts operating in an Oracle WebLogic Server environment.

Note:

For Oracle HTTP Server in standalone mode, see “Configuring Secure Sockets Layer in Standalone Mode” in Administering Oracle HTTP Server.

For outbound traffic, see Enabling SSL for Outbound Requests from Oracle HTTP Server (using either Fusion Middleware Control or WLST).

Parent topic: Configuring SSL for the Web Tier

Enabling SSL for Inbound Requests to Oracle HTTP Server Virtual Hosts Using Fusion Middleware Control

You can SSL-enable inbound traffic to Oracle HTTP Server virtual hosts using these steps:

Select the Oracle HTTP Server instance in the navigation pane on the left.
Create a wallet, if necessary, by navigating to Oracle HTTP Server, then Security, then Wallets.

For details about wallet creation and maintenance, see Managing Keystores, Wallets, and Certificates.
Navigate to Oracle HTTP Server, then Administration, then Virtual Hosts.

This page shows what hosts are currently configured, and whether they are configured for http or https.

Description of the illustration ohsssl1.png
Select the virtual host you wish to update, and click Configure, then SSL Configuration. (Note: If creating a new virtual host, see “Managing Connectivity” in Administering Oracle HTTP Server.)

Description of the illustration ohsssl2.png

The SSL Configuration page appears.
You can convert an https port to http by simply unchecking Enable SSL.
To configure SSL for a virtual host that is currently using http:
- Check the Enable SSL box.
- Select a wallet from the drop-down list.
  
  Description of the illustration ohsssl3.png
- From the Server SSL properties, select the SSL authentication type, cipher suites to use, and the SSL protocol version.
  
  Note:
  
  The default values are appropriate in most situations.
  Note:
  - This assumes that the certificate is available in Fusion Middleware Control. If it was created through orapki, import it first as explained in “Importing a Keystore” in Securing Applications with Oracle Platform Security Services.
  - The choice of authentication type determines the available cipher suites, and the selected cipher suites determine the available protocol versions. For more information about ciphers and protocol versions, see "Properties Files for SSL" in WLST Command Reference for Infrastructure Security.
Click OK to apply the changes.
On Windows platforms only, open Windows Explorer and navigate to your cwallet.sso file. Under properties, security, add SYSTEM in "group or user names".
Restart the Oracle HTTP Server instance by navigating to Oracle HTTP Server, then Control, then Restart.
Open a browser session and connect to the port number that was SSL-enabled.

Parent topic: Enabling SSL for Oracle HTTP Server Virtual Hosts

Enabling SSL for Inbound Requests to Oracle HTTP Server Virtual Hosts Using WLST

Execute these WLST commands using the protocol described in How to Launch the Command-Line Interface.

Take these steps:

Determine the virtual hosts for this Oracle HTTP Server instance by running the following command:
```
listListeners('OHS_instance','OHS_instance' )
```
This command lists all the virtual hosts for this instance. Select the one that needs to be configured for SSL. For example, you can select vhost1. For details about this command, see WLST Command Reference for WebLogic Server.
Configure the virtual host with SSL properties:
```
configureSSL('OHS_instance',
   'OHS_instance',
   'ohs',
   'vhost1')
```
Note:
- configureSSL uses defaults for all SSL attributes; see "Default Values of Parameters" in WLST Command Reference for Infrastructure Security for details.
- You could also specify a properties file as a parameter to configureSSL. See "Parameters in Properties File" and "configureSSL" in the WLST Command Reference for Infrastructure Security for details and examples of how to use a properties file. See "configureSSL" in the same document for details about this command.
On Windows platforms only, open Windows Explorer and navigate to your cwallet.sso file. Under properties, security, add SYSTEM in "group or user names".

Parent topic: Enabling SSL for Oracle HTTP Server Virtual Hosts

Enabling SSL for Outbound Requests from Oracle HTTP Server

You enable SSL for outbound requests from Oracle HTTP Server by configuring mod_wl_ohs.

Parent topic: Enabling SSL for Oracle HTTP Server Virtual Hosts

Enabling One-Way SSL

The steps are as follows:

Generate a custom keystore for Oracle WebLogic Server (see Configuring SSL for Oracle WebLogic Server) containing a certificate.
Import the trusted CA certificate used by Oracle WebLogic Server into the Oracle HTTP Server wallet as a trusted certificate. You can use any available utility such as WLST or Fusion Middleware Control for this task. (Note: The wallet mentioned here is the one that the Oracle HTTP Server listen port uses for SSL. The trusted (root) CA certificate that signed the Oracle WebLogic Server certificate must exist in this wallet. For details on importing trusted certificates see “Importing a Certificate Using Fusion Middleware Control” in Securing Applications with Oracle Platform Security Services.)
With Oracle WebLogic Server instance shut down, edit the Oracle HTTP Server configuration file DOMAIN_HOME/config/fmwconfig/components/OHS/instance_name/ssl.conf and add the following line to the SSL configuration under mod_weblogic:
```
WlSSLWallet  "$(DOMAIN_HOME}/config/fmwconfig/components/COMPONENT_TYPE/COMPONENT_NAME/keystores/default"
```
where default is the name of the Oracle HTTP Server wallet in Step 2.

Here is an example of how the configuration should look:
```
<IfModule mod_weblogic.c>
WebLogicHost myweblogic.server.com
WebLogicPort 7002
MatchExpression *.jsp
SecureProxy On
WlSSLWallet "$(DOMAIN_HOME}/config/fmwconfig/components/OHS/ohs1/keystores/default"
</IfModule>
```
Save the file and exit.
On Windows platforms only, open Windows Explorer and navigate to your cwallet.sso file. Under properties, security, add SYSTEM in "group or user names".
Restart Oracle HTTP Server to activate the changes. See “Restarting Oracle HTTP Server Instances” in Administering Oracle HTTP Server for details.
Ensure that your Oracle WebLogic Server instance is configured to use the custom keystore generated in Step 1, and that the alias points to the alias value used in generating the certificate. Restart the Oracle WebLogic Server instance. For details, see Configuring Inbound SSL to Oracle WebLogic Server.

Parent topic: Enabling SSL for Outbound Requests from Oracle HTTP Server

Enabling Two-Way SSL

mod_wl_ohs also supports two-way SSL communication. To configure two-way SSL:

Perform Steps 1 through 4 of the preceding procedure for one-way SSL.
Generate a trust store, trust.jks, for Oracle WebLogic Server.

The keystore created for one-way SSL (Step 1 of the preceding procedure) could also be used to store trusted certificates, but it is recommended that you create a separate truststore for this procedure.
Export the user certificate from the Oracle HTTP Server wallet, and import it into the truststore created in Step 2.

You can use any available utility such as WLST or Fusion Middleware Control for export, and the keytool utility for import. For details, see Managing the Certificate Life Cycle.
From the Oracle WebLogic Server Administration Console, select the Keystores tab for the server being configured.
Set the custom trust store with the trust.jks file location of the trust store that was created in Step 2 (use the full name).
Set the keystore type as JKS, and set the passphrase used to create the keystore.
Under the SSL tab, ensure that Trusted Certificate Authorities is set as from Custom Trust Keystore.
Ensure that Oracle WebLogic Server is configured for two-way SSL. For details, see "Configuring SSL" in Administering Security for Oracle WebLogic Server.

Parent topic: Enabling SSL for Outbound Requests from Oracle HTTP Server

Configuring SSL for the Middle Tier

SSL in the middle tier of the Oracle Fusion Middleware includes enabling SSL for the application server and also the components and applications running on the application server.

Using SSL in the middle tier includes:

SSL-enabling the application server
SSL-enabling components and applications running on the application server

This section addresses mid-tier SSL configuration and contains these topics:

Configuring SSL for Oracle WebLogic Server
Follow these procedures to configure the application server.
Client-Side SSL for Applications
Find out how to enable SSL for applications on the client side.

Parent topic: Configuring SSL in Oracle Fusion Middleware

Configuring SSL for Oracle WebLogic Server

Follow these procedures to configure the application server.

Parent topic: Configuring SSL for the Middle Tier

Configuring Inbound SSL to Oracle WebLogic Server

For information and details about implementing SSL to secure Oracle WebLogic Server, see the following topics in Administering Security for Oracle WebLogic Server:

Parent topic: Configuring SSL for Oracle WebLogic Server

Configuring Outbound SSL from Oracle WebLogic Server

This section describes how to SSL-enable outbound connections from Oracle WebLogic Server.

Parent topic: Configuring SSL for Oracle WebLogic Server

Configuring Outbound SSL from Oracle Platform Security Services to LDAP

This section explains how to configure SSL (needs server- and client-side) for policy store and credential store connections to an LDAP directory. It supports anonymous and one-way SSL.

See Securing Applications with Oracle Platform Security Services for details about the jps-config.xml file referenced in this section.

Anonymous SSL (Server-side)

Start the LDAP server in anonymous authentication mode.

Consult your LDAP server documentation for information on this task.

Anonymous SSL (Client-side)

In your jps-config.xml file, you must set the protocol to ldaps and specify the appropriate port for the property ldap.url. This information needs to be updated for policy store, credential store, key store and any other service instances that use ldap.url.

One-Way SSL (Client-side)

The following must be in place for the client-side configuration:

The JVM needs to know where to find the trust store that it uses to trust certificates from LDAP. You do this by setting:
```
-Djavax.net.ssl.trustStore=path_to_jks_file
```
This property is added either to the JavaSE program, or to the server start-up properties in a JavaEE environment.
In your jps-config.xml file, you must set the protocol to ldaps and specify the appropriate port for the property ldap.url. This information needs to be updated for policy store, credential store, key store and any other service instances that use ldap.url.
Using keytool, import the LDAP server's certificate into the trust store specified in step 1.

Parent topic: Configuring Outbound SSL from Oracle WebLogic Server

Configuring Outbound SSL from Oracle Platform Security Services to Oracle Database

You can set up a one-way or two-way SSL connection to a database-based OPSS security store.

For details about configuring the database server and clients, see “Setting Up an SSL Connection to the Database Security Store” in Securing Applications with Oracle Platform Security Services.

Parent topic: Configuring Outbound SSL from Oracle WebLogic Server

Configuring Outbound SSL from LDAP Authenticator to LDAP

For details about outbound SSL to LDAP directories, see "How SSL Certificate Validation Works in WebLogic Server" in Administering Security for Oracle WebLogic Server.

Parent topic: Configuring Outbound SSL from Oracle WebLogic Server

Configuring Outbound SSL to the Database

For more information about configuring SSL for the database listener, see "Configuring Secure Sockets Layer Authentication" in the Oracle Database Advanced Security Administrator's Guide.

Parent topic: Configuring Outbound SSL from Oracle WebLogic Server

Client-Side SSL for Applications

Find out how to enable SSL for applications on the client side.

For information on how to write SSL-enabled applications, see "Using SSL Authentication in Java Clients" in Developing Applications with the WebLogic Security Service.

For best practices, refer to Best Practices for Application Developers.

Parent topic: Configuring SSL for the Middle Tier

Configuring SSL for the Data Tier

The data tier of the Oracle Fusion Middleware includes Oracle Database as a component. All components in the data tier must be SSL enabled.

Configuring SSL for the Database
Follow these procedures to enable SSL in the Oracle Database and the Data Sources on Oracle WebLogic Server.

Parent topic: Configuring SSL in Oracle Fusion Middleware

Configuring SSL for the Database

Follow these procedures to enable SSL in the Oracle Database and the Data Sources on Oracle WebLogic Server.

Parent topic: Configuring SSL for the Data Tier

SSL-Enabling Oracle Database

Take these steps to SSL-enable Oracle database:

Create a root CA and a certificate for the DB. Here is an example:

Note:

Self-signed certificates are not recommended for production use. For information about obtain production wallets, see Changing a Self-Signed Wallet to a Third-Party Wallet.

mkdir root
mkdir server
 
# Create root wallet, add self-signed certificate and export
orapki wallet create -wallet ./root -pwd password
orapki wallet add -wallet ./root -dn CN=root_test,C=US -keysize 2048 -self_signed -validity 3650 -pwd password
orapki wallet display -wallet ./root -pwd password
orapki wallet export -wallet ./root -dn CN=root_test,C=US -cert ./root/b64certificate.txt -pwd password
 
#Create server wallet, add self-signed certificate and export
orapki wallet create -wallet ./server -pwd password
orapki wallet add -wallet ./server -dn CN=server_test,C=US -keysize 2048 -pwd password
orapki wallet display -wallet ./server -pwd password
orapki wallet export -wallet ./server -dn CN=server_test,C=US -request ./server/creq.txt -pwd password
 
# Import trusted certificates
orapki cert create -wallet ./root -request ./server/creq.txt -cert ./server/cert.txt -validity 3650 -pwd password
orapki cert display -cert ./server/cert.txt -complete
orapki wallet add -wallet ./server -trusted_cert -cert ./root/b64certificate.txt -pwd password
orapki wallet add -wallet ./server -user_cert -cert ./server/cert.txt -pwd password
orapki wallet create -wallet ./server -auto_login -pwd password}}

Update listener.ora, sqlnet.ora, and tnsnames.ora for the database.

This example shows the default listener.ora:

SID_LIST_LISTENER =
(SID_LIST =(SID_DESC =(SID_NAME = PLSExtProc)(ORACLE_HOME = /path_to_O_H)(PROGRAM = extproc)))
LISTENER =(DESCRIPTION_LIST =(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
(ADDRESS = (PROTOCOL = TCP)(HOST = mynode.mycorp.com)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCPS)(HOST = mynode.mycorp.com)(PORT = 2490))
))
 
WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/wallet_location)))
 
SSL_CLIENT_AUTHENTICATION=FALSE}}

And here is an updated listener.ora file, illustrating a scenario with no client authentication:

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = dbname)
      (ORACLE_HOME = /path_to_O_H)
      (SID_NAME = sid)
    )
  )
 
SSL_CLIENT_AUTHENTICATION = FALSE
 
WALLET_LOCATION =
  (SOURCE =
    (METHOD = FILE)
    (METHOD_DATA =
      (DIRECTORY = /wallet_path)
    )
  )
 
LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = mynode.mycorp.com)(PORT = 1521))
    )
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCPS)(HOST = mycorp.com)(PORT = 2490))
    )
  )

Note that the SSL port has been added.

Likewise, a modified sqlnet.ora file may look like this:

NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
SQLNET.AUTHENTICATION_SERVICES=(BEQ,TCPS,NTS)
WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/directory)))
SSL_CLIENT_AUTHENTICATION=FALSE

A modified tnsnames.ora file may look like this:

OID =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = mynode.mycorp.com)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = mynode.mycorp.com)
    )
  )
   
SSL =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCPS)(HOST = mynode.mycorp.com)(PORT = 2490))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = mynode.mycorp.com)
      or
      (SID = mynode.mycorp.com)
    )
    (SECURITY=(SSL_SERVER_CERT_DN=\"CN=server_test,C=US\"))
  )

Test the connection to the database using the new connect string. For example:
```
$ tnsping ssl
$ sqlplus username/password@ssl
```

See Also:

The chapter "Configuring Secure Sockets Layer Authentication" in the Oracle Database Advanced Security Administrator's Guide.

Parent topic: Configuring SSL for the Database

SSL-Enabling a Data Source

Take these steps to configure your data sources on Oracle WebLogic Server to use SSL.

Create a truststore and add the root certificate (which is created when SSL-enabling the database) as a trusted certificate to the truststore.
In the Oracle WebLogic Server Administration Console, navigate to the Connection pool tab of the data source that you are using.
Note:

The data source can be an existing source such as an Oracle WebCenter Portal data source, or a new data source. See “Creating a JDBC Data Source” in Administering JDBC Data Sources for Oracle WebLogic Server for details.

The properties you need to specify in the JDBC Properties text box depend on the type of authentication you wish to configure.
- If you will require client authentication (two-way authentication):
```
javax.net.ssl.keyStore=..(password of the keystore)
       javax.net.ssl.keyStoreType=JKS
       javax.net.ssl.keyStorePassword=...(password of the keystore)
       javax.net.ssl.trustStore=...(the truststore location on the disk)
       javax.net.ssl.trustStoreType=JKS
       javax.net.ssl.trustStorePassword=...(password of the truststore)
```
- If you will require no client authentication:
```
javax.net.ssl.trustStore=...(the truststore location on the disk)
       javax.net.ssl.trustStoreType=JKS
       javax.net.ssl.trustStorePassword=...(password of the truststore)
```

In the URL text box, enter the JDBC connect string. Ensure that the protocol is TCPS and that SSL_SERVER_CERT_DN contains the full DN of the database certificate.

Use the following syntax if tnsnames.ora uses "SERVICE_NAME":

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCPS)(HOST=host-name)(PORT=port-number)))(CONNECT_DATA=(SERVICE_NAME=service))(SECURITY=(SSL_SERVER_CERT_DN="CN=server_test,C=US")))

Use the following syntax if tnsnames.ora uses "SID":

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCPS)(HOST=host-name)(PORT=port-number)))(CONNECT_DATA=(SID=service))(SECURITY=(SSL_SERVER_CERT_DN="CN=server_test,C=US")))

Test and verify the connection. Your data source is now configured to use SSL.

Parent topic: Configuring SSL for the Database

Setting Up One-Way SSL to the LDAP Security Store

Follow these steps to set up a one-way Secure Sockets Layer (SSL) channel between Oracle WebLogic Server or a Java SE application, and the LDAP security store. Such connection may be required, for example, when reassociating to an LDAP target store.

Configure LDAP

For information about how to configure LDAP with one-way SSL, see "Enabling SSL on Oracle Internet Directory Listeners" in Administrator's Guide for Oracle Internet Directory.

Create the LDAP Certificate Authority

If the LDAP certificate authority is unknown to WebLogic Server, then use orapki to export a certificate:

orapki wallet export -wallet CA -dn "CN=myCA" -cert serverTrust.cert

This command exports a certificate from a wallet to a file that is specified by —cert.

Before configuring SSL, note that:

The following procedures are required if the type of SLL is server-auth and mutual-auth and not required for no-auth.
If the flags specified in the procedures below are used in an environment where multiple applications run, then these applications must use the same truststore.

Setting Up for Java EE Applications

Use one of the following procedures to set up a one-way SSL connection between the server and the identity store. The procedures differ because the identity store and security store services use different socket factories.

To establish one-way SSL connections between the server and the identity store (if applicable, then it is assumed that the trust certification authority (CA) has been exported):

If the CA is known to WebLogic Server, then skip this step.

Otherwise, use keytool to import the LDAP CA into the truststore as in the following example which generates the myKeys.jks file and imports the serverTrust.cert file:
```
>keytool -import -v -trustcacerts -alias trust -file serverTrust.cert -keystore myKeys.jks -storepass keyStorePassword
```
Modify the startWebLogic.sh script that starts the server to include a line like the following, and then run the script:
```
-Djavax.net.ssl.trustStore=<absolute path name to file myKeys.jks>
```

To establish a one-way SSL connection between the server and the security store (if applicable, then it is assumed that the trust CA has been exported):

Use keytool to import trust CA to the truststore:

>keytool -import -v -trustcacerts -alias trust -file serverTrust.cert -keystore myKeys.jks -storepass keyStorePassword

Modify the startWebLogic.sh script that starts the server to include a line like the following, and then run the script:
```
-Dweblogic.security.SSL.trustedCAKeyStore=<absolute path name to file myKeys.jks>
```
If the LDAP server uses a wild card in the SSL certificate, then add the following line to the script that starts WebLogic Server:
```
-Dweblogic.security.SSL.ignoreHostnameVerification=true
```
Restart the server.

Setting Up for Java SE Applications

If the CA is known to WebLogic Server, then skip this step.

Otherwise, use keytool to import the LDAP CA into the truststore as in the following example, which generates the myKeys.jks file and imports the serverTrust.cert file:
```
>keytool -import -v -trustcacerts -alias trust -file serverTrust.cert -keystore myKeys.jks -storepass keyStorePasswodr
```
Modify the script that starts the Java Virtual Machine (JVM) to include a line like the following:
```
-Djavax.net.ssl.trustStore=<absolute path name to file myKeys.jks>
```
Restart the server.

Parent topic: Configuring SSL in Oracle Fusion Middleware

Setting Up SSL in Identity Store Services

Establishing SSL connections in Identity Store Services using libOVD and JKS requires keystore certificates that are kept in multiple locations, such as the WebLogic Server truststore and the adapters.jks file.

Table 6-2 SSL with JKS

Virtualize Flag	Using the User and Role API	Using the Identity Directory API
`virtualize=false`	Specify the truststore as explained in Setting Up One-Way SSL to the LDAP Security Store.	Use `adapters.jks` as shown in Setting up One-Way SSL in Identity Store Services using libOVD and JKS and Setting up Two-Way SSL in Identity Store Services using libOVD and JKS.
`virtualize=true`	Use `adapters.jks` as shown in Setting up One-Way SSL in Identity Store Services using libOVD and JKS and Setting up Two-Way SSL in Identity Store Services using libOVD and JKS.	Use `adapters.jks` as shown in Setting up One-Way SSL in Identity Store Services using libOVD and JKS and Setting up Two-Way SSL in Identity Store Services using libOVD and JKS.

Setting up One-Way SSL in Identity Store Services using libOVD and JKS
Follow these steps to establish one-way SSL in Identity Store Services using libOVD and JKS.
Setting up Two-Way SSL in Identity Store Services using libOVD and JKS
Follow these steps to establish two-way SSL in Identity Store Services using libOVD and JKS.

Parent topic: Configuring SSL in Oracle Fusion Middleware

Setting up One-Way SSL in Identity Store Services using libOVD and JKS

Follow these steps to establish one-way SSL in Identity Store Services using libOVD and JKS.

Create a keystore to contain the LDAP server certificate(s) for use by the service. You must provide passwords for Oracle WebLogic Server Administration Console and the keystore, respectively. Before running libovdconfig.sh, set ORACLE_HOME to oracle_common.
To create the keystore run MW_HOME/oracle_common/bin/libovdconfig.sh with the createKeystore option:
```
libovdconfig.sh -host wls_host -port wls_adminserver_port -userName wls_user_name -domainPath full_path_domain_home -createKeystore
```
where:
- host is the server host
- port is the WebLogic Administration Server port
- username is the administrator user name
- domainPath is the complete path to the domain home
Export the certificate from the LDAP directory with the LDAP utility export.

Import the certificate to the created keystore with the keytool command:

$JAVA_HOME/bin/keytool -importcert 
-keystore $DOMAIN_HOME/config/fmwconfig/ovd/default/keystores/adapters.jks 
-storepass keystore_password_used_in_libovdconfig.sh 
-alias alias_name 
-file full_path_to_LDAPCert_file 
-noprompt

Restart WebLogic Server.

Parent topic: Setting Up SSL in Identity Store Services

Setting up Two-Way SSL in Identity Store Services using libOVD and JKS

Follow these steps to establish two-way SSL in Identity Store Services using libOVD and JKS.

Perform the procedure described in Setting up One-Way SSL in Identity Store Services using libOVD and JKS.
In the keystore that was created, generate a new signed certificate.
Export this certificate to a file.
Import the certificate into the LDAP directory.

Parent topic: Setting Up SSL in Identity Store Services

Advanced SSL Scenarios

SSL configuration in Oracle Fusion Middleware also includes additional scenarios that are beyond the basic topologies like FIPS 140 support, Hardware Security Modules and certificate validation.

Hardware Security Modules and Accelerators
A Hardware Security Module (HSM) is a physical plug-in card or an external security device that can be attached to a computer to provide secure storage and use of sensitive content.
CRL Integration with SSL
Find out how to configure a component to use CRL-based validation, and how to create and set up CRLs on the file system.
Oracle Fusion Middleware FIPS 140-2 Settings
Review this topic for setting up FIPS 140–2 among the different components of the Oracle Fusion Middleware.

Parent topic: Configuring SSL in Oracle Fusion Middleware

Hardware Security Modules and Accelerators

A Hardware Security Module (HSM) is a physical plug-in card or an external security device that can be attached to a computer to provide secure storage and use of sensitive content.

Note:

This discussion applies only to Oracle HTTP Server, which is a system component supporting HSM.

Oracle Fusion Middleware supports PKCS#11-compliant HSM devices that provide a secure storage for private keys.

Take these steps to implement SSL for a component using a PKCS#11 wallet:

Install the HSM libraries on the machine where the component is running. This is a one-time task and is device-dependent.
Next, create a wallet using the orapki command-line tool. Note the following:
1. Choose PKCS11 as the wallet type.
2. Specify the device-specific PKCS#11 library used to communicate with the device. This library is part of the HSM software.
  
  On Linux, the library is located at:
```
For LunaSA (Safenet):  /usr/lunasa/lib/libCryptoki2.so
For nCipher:  /opt/nfast/toolkits/pkcs11/libcknfast.so
```
  On Windows, the library is located at:
```
For LunaSA (Safenet): C:\Program Files\LunaSA\cryptoki.dll
```
Now follow the standard procedure for obtaining third-party certificates: create a certificate request; get the request approved by a Certificate Authority (CA); and install the certificate signed by that CA.

The wallet you set up is used like any other wallet.
Verify the wallet with the orapki utility. Use the following command syntax:
```
orapki wallet p11_verify [-wallet [wallet]] [-pwd password]
```
See Also:

orapki for details about orapki
Configure SSL on your component listener using the configureSSL WLST command, providing a properties file as input. Your properties file should specify the full path of the PKCS#11 wallet directory on the machine where the component is running. (Note: Do not save the PKCS#11 wallet in the instance home directory. Only wallets created and managed through Fusion Middleware Control or WLST should reside in the instance home.)

A sample properties file could look like this:
```
SSLEnabled=true
AuthenticationType=Server
PKCS11Wallet=/tmp/lunasa/wallet 
```

Note:

You must use the WLST command configureSSL to configure the PKCS11 wallet. You cannot do this task using Fusion Middleware Control or any other tool.

Parent topic: Advanced SSL Scenarios

CRL Integration with SSL

Find out how to configure a component to use CRL-based validation, and how to create and set up CRLs on the file system.

Note:

This discussion applies only to Oracle HTTP Server in the context of an Oracle WebLogic Server environment. For SSL configuration in standalone components, see Administering Oracle HTTP Server.
Manage CRL validation through WLST. You cannot perform this task through Fusion Middleware Control.

Components that use SSL can optionally turn on certificate validation using a certificate revocation list (CRL). This allows them to validate the peer certificate in the SSL handshake and ensure that it is not on the list of revoked certificates issued by the Certificate Authority (CA).

Parent topic: Advanced SSL Scenarios

Configuring CRL Validation for a Component

Configure SSL on your component listener using the configureSSL WLST command, providing a properties file as input.

The properties file must be set up as follows:

The CertValidation attribute must be set to url.
The CertValidationPath attribute must be of the form file://file_path or dir://directory_path.
- Use the first format if you are using a single CRL file for certificate validation. This CRL file should contain a concatenation of all CRLs.
- Use the second format if you are specifying a directory path that contains multiple CRL files in hashed form.
  
  See Manage CRLs on the File System on how to create CRLs in hashed form.

In this example, the properties file specifies a single CRL file:

SSLEnabled=true
AuthenticationType=Server
CertValidation=crl
KeyStore=ohs1 
CertValidationPath=file:///tmp/file.crl

In this example, the properties file specifies a directory path to multiple CRL files:

SSLEnabled=true
AuthenticationType=Server
KeyStore=ohs1 
CertValidation=crl
CertValidationPath=dir:///tmp

Parent topic: CRL Integration with SSL

Manage CRLs on the File System

Note:

LDAP-based CRLs or CRL distribution points are not supported.

You use the orapki command-line tool to manage CRLs on the file system. For details on this topic, see Managing Certificate Revocation Lists with orapki Utility.

CRL Renaming to Hashed Form

If specifying a CRL storage location, the CRL must be renamed. This enables CRLs to be loaded in an efficient manner at runtime. This operation creates a symbolic link to the actual CRL file. On Windows, it copies the CRL to a file with a new name.

To rename a CRL:

orapki crl hash 
[-crl [url|filename]] [-wallet wallet] [-symlink directory] 
[-copy directory] [-summary] [-pwd password]

For example:

orapki crl hash -crl nzcrl.txt -symlink wltdir -pwd password

If the CRL file name is specified at runtime, multiple CRLs can be concatenated in that file. The CRL created in this example is in Base64 format, and you can use a text editor to concatenate the CRLs.

CRL Creation

Note:

CRL creation and Certificate Revocation are for test purposes and only used in conjunction with self-signed certificates. For production use, obtain production certificates from well-known CAs and obtain the CRLs from those authorities.

To create a CRL:

orapki crl create 
[-crl [url|filename]] [-wallet [cawallet]] [-nextupdate [days]] [-pwd password]

For example:

orapki crl create 
-crl nzcrl.crl -wallet rootwlt -nextupdate 3650 -pwd password

Certificate Revocation

Revoking a certificate adds the certificate's serial number to the CRL.

To revoke a certificate:

orapki crl revoke 
[-crl [url|filename]] [-wallet [cawallet]] [-cert   [revokecert]] [-pwd password]

For example:

orapki crl revoke 
-crl nzcrl.txt -wallet rootwlt -cert cert.txt -pwd password

Parent topic: CRL Integration with SSL

Test a Component Configured for CRL Validation

To test that a component is correctly configured for CRL validation, take these steps:

Set up a wallet with a certificate to be used in your component.
Generate a CRL with this certificate in the revoked certificates list. Follow the steps outlined in Manage CRLs on the File System.
Configure your component to use this CRL. Follow the steps outlined in Configuring CRL Validation for a Component.
The SSL handshake should fail when this revoked certificate is used.

Parent topic: CRL Integration with SSL

Oracle Fusion Middleware FIPS 140-2 Settings

Review this topic for setting up FIPS 140–2 among the different components of the Oracle Fusion Middleware.

For details about FIPS 140 support in Oracle Fusion Middleware, see FIPS 140 Support in Oracle Fusion Middleware.

Parent topic: Advanced SSL Scenarios

Best Practices for SSL

Oracle Fusion Middleware recommends some best practices for component administrators and application developers while configuring SSL.

Best Practices for Administrators
For a successful system administration, you must follow these best practices.
Best Practices for Application Developers
Application Developers must follow these practices that are recommended.

Parent topic: Configuring SSL in Oracle Fusion Middleware

Best Practices for Administrators

For a successful system administration, you must follow these best practices.

Use self-signed wallets only in test environment. You should obtain a CA signed certificate in the wallet before moving to production environment. For details, see Managing Keystores, Wallets, and Certificates.
It is recommended that components (at least in the Web tier) use certificates that have the system host name or virtual host or site name as the DN. This allows browsers to connect in SSL mode without giving unsettling warning messages.
A minimum key size of 1024 bits is recommended for certificates used for SSL. Higher key size provides more security but at the cost of reduced performance. Pick an appropriate key size value depending on your security and performance requirements.
Lack of trust is one of the most common reasons for SSL handshake failures. Ensure that the client trusts the server (by importing the server CA certificate into the client keystore) before starting SSL handshake. If client authentication is also required, then the reverse should also be true.

Parent topic: Best Practices for SSL

Best Practices for Application Developers

Application Developers must follow these practices that are recommended.

Use Java Key Store (JKS) to store certificates for your Java EE applications.
Externalize SSL configuration parameters like keystore path, truststore path, and authentication type in a configuration file, rather than embedding these values in the application code. This allows you the flexibility to change SSL configuration without having to change the application itself.

Parent topic: Best Practices for SSL

WLST Reference for SSL

WLST commands are available to manage Oracle wallets and to configure SSL for Oracle Fusion Middleware components.

See the following chapters of the WLST Command Reference for Infrastructure Security for details about these WLST commands:

See Also:

Command-Line Interface for Keystores and Wallets for important instructions on how to launch the WLST shell to run SSL-related commands. Do not launch the WLST interface from any other location.

Note:

All WLST commands for SSL configuration must be run in online mode.

Note:

WLST allows you to import certificates only in PEM format.

Parent topic: Configuring SSL in Oracle Fusion Middleware