Configuring SSL

The Secure Sockets Layer (SSL) protocol provides communication security by encrypting traffic across a network in a way designed to prevent eavesdropping and tampering. It uses asymmetric cryptography for privacy and a keyed message authentication code for message reliability. Setting up an SSL-secured connection requires a digital certificate issued by a trusted certificate authority. Self-signed digital certificates should only be used for internal testing.

Oracle recommends that all OHI Components applications related data communication, whether it is browser or web services based and whether it is within the organization’s firewall or accessed through VPN, is at least secured using SSL.

Configuring SSL in WebLogic

WebLogic Application Server supports SSL 3.0 and Transport Layer Security (TLS) 1.0 specifications. WebLogic does not support SSL version 2.0 and below.
For information on how to configure SSL in WebLogic please visit the following URLs:

Configuring SSL for Authentication: using LDAPS

OHI Components applications delegate authentication requests using configurable WebLogic authentication providers. Typically, authentication requests are delegated to an LDAP server. WebLogic authentication providers can authenticate using SSL-secured traffic by configuring the LDAP connect string to use LDAPS, e.g. ldaps://<machine>.<domain>:<ssl_port>. The SSL port for the LDAP protocol is usually 636.

This paragraph describes the configuration for enabling SSL encrypted traffic between OHI Components applications and Oracle Internet Directory (OID). OID supports three SSL Modes that are listed in the following table.

SSL Authentication Methods Description Supported by
OHI
Components?

Mode 1: No SSL Authentication

Neither the client nor the server authenticates itself to the other. No certificates are sent or exchanged. Only SSL encryption and decryption is used.

No

Mode 2: SSL Server Authentication

The directory server authenticates itself to the client. The directory server sends the client a certificate verifying that the server is authentic.

Yes

Mode 3: SSL Client and Server Authentication

The client and server authenticate themselves to each other and send certificates to each other.

Yes

To use the LDAPS feature, an SSL certificate needs to be obtained and installed on the Directory Server. Recommended steps for configuring Oracle Internet Directory 11g (OID) SSL Server Authentication (mode 2) are listed in this paragraph. The listed process is applicable for OID releases 11.1.1.2 to 11.1.1.4 and is based on Support Article 1203271.1 that is published on the Oracle Support website (and takes precedence over the product documentation). Article 1203271.1 covers steps 1 to 4 in the following list:

Support Article 1203271.1 suggests to create an additional OID Instance / Configset. Rationale as given in the article: "By default, the SSL authentication mode is set to authentication mode 1 (encryption only, no authentication). Be sure at least one Oracle Internet Directory server instance has this default authentication mode. Otherwise, you break Oracle Delegated Administration Services and other applications that expect to communicate with Oracle Internet Directory on the encrypted SSL port.". Create an additional OID instance (requires migrating the data of the original instance) or make sure that a configuration set is configured to also support authentication mode 1.

Use the Fusion Middleware Enterprise Manager to create a Wallet. For test systems Self-Signed Wallets are sufficient. For production systems Self-Signed Certificates are not recommended: Self-Signed Certificates typically lead to Certificate Trust messages. Users could react to these messages but in OHI Components applications the user authentication process will fail as a result of an error in the SSL handshake. Create a proper Wallet for production systems.
For a production setup, generate a certificate request and send that to a Certificate Authority (CA). Import the SSL certificate that was issued by the CA before continuing with the following step.

Enable SSL for the OID server using the Wallet that was created in the previous step.

Restart the OID instance.

Stop the WebLogic (managed) servers that execute the OHI Components application.

If a Self-Signed certificate was used, prevent Certificate Trust warnings that will break the authentication process by importing the self-signed root certificate in the
cacerts certificates store of the JVM that executes the OHI Components application.

  1. Export the Self-Signed root certificate from the Self-Signed Wallet using the Fusion Middleware Enterprise Manager.

  2. Make a backup of the JVM’s cacerts file.

  3. Import the root certificate into the cacerts certificate store using the keytool. In the following example alias is a self-chosen, meaningful name for the root + certificate (note: the alias has to be unique within the cacerts file)
    keytool -import -trustcacerts -keystore cacerts -storepass storepass -noprompt -alias <alias> -file <path_to_exported_root_certificate_file>

Start the WebLogic (managed) servers that executes the OHI Components application.

In the WebLogic Console, in the "Provider Specific" settings tab of the OHIAuthenticationProvider, set the SSLEnabled flag (restart of WebLogic server required).

Test the setup. If an additional OID instance was created and the original instance is no longer needed, the original OID Instance / Configuration set can be stopped using opmnctl. Optionally, it can be removed.

Configuring SSL for Coherence

OHI Components applications use an Oracle Coherence distributed cache that is shared between multiple cluster nodes. It is expected that all cluster nodes reside in the same security zone, i.e. the OHI application server and database zone. Coherence provides an SSL implementation that secures TCMP communication between cluster nodes that can be enabled if required. For information on how to configure SSL to secure Coherence TCMP traffic please see the Coherence Security Guide.