SSL for Essbase 11.1.2.4

Overview

This section explains the procedures for replacing the default certificates that are used to secure communication between an Oracle Essbase instance and components such as MaxL, Oracle Essbase Administration Services Server, Oracle Essbase Studio Server, Oracle Hyperion Provider Services, Oracle Hyperion Foundation Services, Oracle Hyperion Planning, Oracle Hyperion Financial Management, and Oracle Hyperion Shared Services Registry.

Default Deployment

Essbase can be deployed to work in SSL and non-SSL modes. Essbase Agent listens on a non-secure port; it also can be configured to listen on a secure port. All connections accessing the secure port are treated as SSL connections. If a client connects to the Essbase Agent on the non-SSL port, the connection is treated as a non-SSL connection. Components can establish concurrent non-SSL and SSL connections to an Essbase Agent.

You can control SSL on a per-session basis by specifying the secure protocol and port when you log in. See Establishing a Per-Session SSL Connection.

If SSL is enabled, all communication within an Essbase instance is encrypted to ensure data security.

Default deployments of Essbase components in secure mode uses self-signed certificates to enable SSL communication, mainly for testing purposes. Oracle recommends that you use certificates from well-known third-party CAs to SSL-enable Essbase in production environments.

Typically, an Oracle Wallet stores the certificate that enables SSL communication with clients that use Essbase RTC and a Java keystore stores the certificate that enables SSL communication with components that utilize JAPI for communication. To establish SSL communication, Essbase clients and tools store the root certificate of the CA that signed the Essbase Server and Agent certificates. See Required Certificates and Their Location.

Required Certificates and Their Location

Oracle recommends the use of certificates from well-known third-party CAs to SSL-enable Essbase in a production environment. You may use the default self-signed certificates for test purposes.

Note:

Essbase supports the use of wildcard certificates, which can secure multiple subdomains with one SSL certificate. Using a wildcard certificate can reduce management time and cost.

Wildcard certificates cannot be used if host-name check is enabled.

You require the following certificates:

A root CA certificate.
Components that use Essbase RTC to establish a connection to Essbase require that the root CA certificate be stored in an Oracle Wallet. Components that use JAPI to establish a connection require that the root CA certificate be stored in a Java keystore. The required certificates and their locations are indicated in the following table.

Note:

You may not need to install root CA certificate if you are using certificates from a well-known third-party CA whose root certificate is already installed in Oracle Wallet.
Signed certificate for Essbase Server and Essbase Agent.

Table 2-1 Required Certificates and Their Locations

Component¹	Keystore	Certificate ²
MaxL	Oracle Wallet	Root CA certificate
Administration Services Server	Oracle Wallet	Root CA certificate
Provider Services	Oracle Wallet	Root CA certificate
Oracle Enterprise Performance Management System Database	Oracle Wallet	Root CA certificate
Essbase Studio Server	Java Keystore	Root CA certificate
Planning	Oracle Wallet Java Keystore	Root CA certificate
Financial Management	Java Keystore	Root CA certificate
Essbase (Server and Agent) ³	Oracle Wallet Java Keystore	Root CA certificate Signed certificate for Essbase Server and Agent
Oracle Hyperion Shared Services Repository
¹ You need only one instance of the keystore to support multiple components that use a similar keystore. ² Multiple components can use a root certificate installed in a keystore. ³ Certificates must be installed in the default Oracle Wallet and in the Java keystore.