This chapter describes how to configure Oracle Business Intelligence components to communicate over the Secure Socket Layer (SSL).
Note:
For a detailed list of security setup steps, see Section 1.7, "Detailed List of Steps for Setting Up Security in Oracle Business Intelligence".The SSL Everywhere feature of Oracle Business Intelligence enables secure communications between the components. You can configure SSL communication between the Oracle Business Intelligence components and between Oracle WebLogic Server for secure HTTP communication across your deployment. This section does not cover configuring secure communications to external services, such as databases and web servers. For information about how to configure SSL for Oracle WebLogic Server, see "SSL Configuration in Oracle Fusion Middleware" in Oracle Fusion Middleware Administrator's Guide.
This chapter contains the following sections:
SSL is a cryptographic protocol that enables secure communication between applications across a network. Enabling SSL communication provides several benefits, including message encryption, data integrity, and authentication. An encrypted message ensures confidentiality in that only authorized users have access to it. Data integrity ensures that a message is received intact without any tampering. Authentication guarantees that the person sending the message is who he or she claims to be.
SSL requires that the server possess a public key and a private key for session negotiation. The public key is made available through a server certificate signed by a certificate authority. The certificate also contains information that identifies the server. The private key is protected by the server.
This section contains the following topics:
For more information about SSL concepts and public key cryptography, see "How SSL Works" in Oracle Fusion Middleware Administrator's Guide.
Oracle Business Intelligence components communicate with each other using TCP/IP by default. Configuring SSL between the Oracle Business Intelligence components enables secured network communication.
Oracle Business Intelligence components can communicate only through one protocol at a time. It is not possible to use SSL between some components, while using simple TCP/IP communications between others. To enable secure communication, all instances of the following Oracle Business Intelligence components must be configured to communicate over SSL:
Oracle BI Server
Oracle BI Presentation Services
Oracle BI JavaHost
Oracle BI Scheduler
Oracle BI Job Manager
Oracle BI Cluster Controller
Oracle BI Server Clients, such as Oracle BI ODBC Client
SSL is configured throughout the Oracle Business Intelligence installation from a single centralized point. Certificates are created for you and every Oracle Business Intelligence component (except Essbase) is configured to use SSL. The following default security level is configured by SSL:
SSL encryption is enabled.
Mutual SSL authentication is not enabled. Since mutual SSL authentication is not enabled, clients do not need their own private SSL keys.
The default cipher suites are used. For information about how to use a non-default cipher suite, see Section 5.13, "Manually Configuring SSL Cipher Suite".
When scaling out, the centrally managed SSL configuration is automatically propagated to any new components that are added.
If a higher level of security is required, manual configuration might be used to augment or replace the SSL central configuration. This is considerably more complex. For more information about how to configure SSL manually, contact Oracle Support. For more information, see Documentation Accessibility.
Secure communication over SSL requires certificates signed by a certificate authority (CA). For internal communication, the SSL Everywhere feature creates both a private certificate authority and the certificates for you. The internal certificates cannot be used for the outward facing web server because user web browsers are not aware of the private certificate authority. The web server must therefore be provided with a web server certificate signed by an externally recognized certificate authority.
To achieve end to end SSL you need to configure both internal BIEE SSL and WebLogic SSL. The internal SSL configuration is highly automated whereas the WebLogic SSL configuration requires multiple manual steps. The two are entirely independent, so can be performed in either order. Since the WebLogic configuration requires manual steps Oracle advises doing that first.
Note:
This section does not include configuring SSL for Essbase.Perform the following steps. Confirmation steps are highlighted:
To configure a standard non-SSL Oracle Business Intelligence system:
Install BIEE.
Confirm the system is operational.
Check you can login over http to use:
Analytics
- http://<Host>:< ManagedServerPort >/analytics
Fusion Middleware Control
- http://<Host>:< AdminPort>/em
WebLogic Admin Console
- http://<Host>:<AdminPort>/console
These steps configure WebLogic using the provided demo certificates. These are not secure. They must not be used in a production environment. Nevertheless configuring with demo certificates first is a useful familiarization exercise prior to configuring with real certificates.
To configure with a secure certificate signed by a real Certificate Authority see WebLogic documentation. The certificate authority should return the signed server certificate, and provide a corresponding root CA certificate. Where ever democa is mentioned in these steps replace with your real CA certificate.
This section contains the following topics:
Section 5.2.2.3, "Configuring Internal WebLogic Server LDAP to Use LDAPs"
Section 5.2.2.4, "Configuring Internal WebLogic Server LDAP Trust Store"
To start only the admin server:
Starting up just the Administration Server rather than starting everything avoids the need to stop everything while the admin connection properties are in a state of flux, which confuses the stop everything script.
Stop everything with:
<DomainHome>/bitools/bin/stop.sh
Start up just the admin server with:
<DomainHome>/bitools/bin/start.sh -i Adminserver
To configure HTTPs Ports:
Login to WebLogic Admin console.
Click Lock and Edit.
Select environment, servers.
For each server:
On the main Configuration tab, select SSL Listen Port Enabled.
Click Save.
Click Activate Changes.
Enable trust of demo certificates in your browser:
If you are using WebLogic demo certificates your browser will not trust the WebLogic server. You will need to enable trust in your browser. If using a standard Certificate Authority whose certificates are trusted by default by your browser then you can omit this step.
Go to URL https://<host>:<AdminServerSSLPort>
Note that this is the base URL, with no em or console on the path. By first accessing the base URL you can set up a single browser certificate exception. If you go directly to the em and console paths you will have to setup multiple certificate exceptions.
Your browser will warn you about the demo certificate.
Enable the certificate exception by going to the base URL.
You only have to do this once, rather than separately for WebLogic console and Fusion Middleware Control.
The base URL should give a 404 error once the ssl connection is made. This is fine.
Check the secure WebLogic console URL:
https://<Host>:<AdminServerSSLPort>/console
Check the secure Fusion Middleware Control URL:
https://<Host>:<AdminServerSSLPort>/em
Do not disable HTTPs yet. You will run a script later that needs to access the Admin Server using the non-SSL port.
Note: HTTPs check should be in existing browser already logged into Fusion Middleware Control using HTTP.
Enabling secure replication:
In WebLogic Admin Console:
Click Lock and Edit.
Select Environment, Clusters, and bi_cluster.
Select Configuration, and the Replication tab. '
Select secure replication enabled.
If you do not do this, the managed servers will fail to startup, remaining in admin mode. This prevents the start scripts from running.
Click Save.
Click Activate Changes.
If an external Identity Store has already been configured omit this step. You may later wish to configure the external identity store to use a secure connection. The steps to do that depend on the type of external identity store.
The internal LDAP ID Store must have its URL amended.
Note:
This section only applies when using WebLogic Server LDAP and when virtualize=true is not set, as you are explicitly pointing the Adminserver.To configure internal LDAPs to use HTTPs:
Login to Fusion Middleware Control 12c:
https://<Host>/<SecureAdminPort>/em
Select WebLogic Domain, Security, Security Provider Configuration.
Expand the Identity Store Provider segment.
Click Configure.
Click the plus symbol (+) to add a new property.
Add a property ldap.url, with the value:
ldaps://<host>:<adminServer HTTPS port>.
For example:
ldaps://example_machine.com:9501
Note: This is the admin server address, not the bi_server1 address.
Click OK in the property editor.
Click OK in the Identity Store Provider page.
Confirm that the change has been made.
Open the jps-config.xml file located in:
<DomainHome>/config/fmwconfig/jps-config.xml.
Check the file contains the line:
<property name="ldap.url" value="ldaps://<Host>:<AdminServerSecurePort>"/>
You must now provide a trust keystore.
For a full description see: "One-way SSL in a Multi-LDAP Scenario" in Oracle Fusion Middleware Application Security Guide.
Note:
This section only applies when using WebLogic Server LDAP and when virtualize=true is set, as you are explicitly pointing the Adminserver.To configure the internal LDAP trust store:
In a terminal window set the environment variables ORACLE_HOME and WL_HOME.
For example, on Linux:
setenv ORACLE_HOME <OracleHome>
setenv WL_HOME <OracleHome>/wlserver/
Ensure that both your path and JAVA_HOME point to the JDK 8 installation.
setenv JAVA_HOME <path_to_your_jdk8>
setenv PATH $JAVA_HOME/bin
Check the java version by running:
java -version
Run (without the line breaks):
<OracleHome>/oracle_common/bin/libovdconfig.sh
-host <Host>
-port <AdminServerNonSSLPort>
-userName <AdminUserName>
-domainPath <DomainHome>
-createKeystore
When prompted enter the existing password for <AdminUserName>.
When prompted for the OVD Keystore password, choose a new password. You will need this later.
For example:
oracle_common/bin/libovdconfig.sh -host myhost -port 7001 -userName weblogic -domainPath /OracleHome/user_projects/domains/bi -createKeystore Enter AdminServer password: Enter OVD Keystore password: OVD config files already exist for context: default CSF credential creation successful Permission grant already available for context: default OVD MBeans already configured for context: default Successfully created OVD keystore.
Note: The -port <AdminServerNonSSL> command does not work against the Admin server non-SSL port when it has been disabled. If you enable SSL and then configure LDAPs you would need to temporarily re-enable the non-SSL port on the Adminserver.
Check the resultant keystore exists, and see its initial contents, by running:
keytool -list -keystore <DomainHome>/config/fmwconfig/ovd/default/keystores/adapters.jks
We now need to export the demo certificate in a suitable format to import into the above keystore.
In Fusion Middleware Control:
If using the demo WebLogic certificate you can get the required root CA from the system keystore using Fusion Middleware Control.
Select WebLogicDomain, Security, Keystore.
Expand System.
Select Trust.
Click Manage.
Select democa (NOT olddemoca).
Click Export.
Select export certificate.
Choose a file name.
For example, demotrust.pem
If not using the demo WebLogic certificate then you will need to obtain the root CA of the CA which singed your secure server certificate.
Now import into the just created keystore:
keytool -importcert -keystore <DomainHome>/config/fmwconfig/ovd/default/keystores/adapters.jks -alias localldap -file <DemoTrustFile>
When prompted enter the keystore password you chose earlier, and confirm that the certificate is to be trusted.
If you repeat the keystore -list command you should see a new entry under localldap, for example:
localldap, Jul 8, 2015, trustedCertEntry,
Certificate fingerprint (SHA1):
CA:61:71:5B:64:6B:02:63:C6:FB:83:B1:71:F0:99:D3:54:6A:F7:C8
The system is only fully secure if in addition to HTTPS being enabled we also disable HTTP.
To disable HTTP:
Login to WebLogic Admin console.
Click Lock & Edit.
Select environment, servers.
For each server:
Display the Configuration tab
Clear Listen Port Enabled.
Click Save.
Click Activate Changes.
To restart Oracle Business Intelligence:
Stop the Administration Server from within WebLogic Admin console.
Everything should now be stopped.
Use the <DomainHome>/bitools/bin/start.sh script to start everything.
You won't yet be able to login through Analytics since Oracle Web Service Manager (OWSM) is still using the disabled HTTP port.
Confirm that HTTP is disabled by logging into both the HTTP and HTTPs WebLogic console URLs. Only the HTTPs one should work.
HTTP should quickly display an 'Unable to connect error' (the wording varies with the browser). Be careful not to mix the protocols and ports. The browser may hang when attempting to connect to a running port with the wrong protocol.
You must now change the Oracle Web Services Manager (OWSM) configuration to use the HTTPs port.
To configure OWSM to use t3s:
Login to Fusion Middleware Control 12c.
https://<Host>/<SecureAdminPort>/em).
Select WebLogic domain, and cross component wiring, components.
Select component type, OWSM agent.
Select the row owsm-pm-connection-t3 status 'Out of Sync', and click 'Bind'.
The HTTP(s) OWSM link is not used when using a local OWSM.
Select Yes in the pop-up box.
Confirm by accessing the policy via the validator:
https://<host>:<ManagedServerSSLPort>/wsm-pm/validator
To restart Oracle Business Intelligence:
Stop all servers using the <DomainHome>/bitools/bin/stop.sh script.
Everything should now be stopped.
Use the <DomainHome>/bitools/bin/start.sh script to start everything.
Confirm that you can login to Analytics at:
https://<Host>:<SecureManagedServerPort>/analytics
The WebLogic tier is now using HTTPs only for its outward facing ports and therefore for all WebLogic infrastructure. The internal BI channel and BI system components are still using HTTP.
This section describes how to enable SSL on internal communication links.
To enable BIEE internal SSL:
You must run commands from the master host. Oracle Business Intelligence must have been configured by the BI configuration assistant, WebLogic managed servers must have been created, and any scaling out must be complete.
Stop the system using:
ORACLE_HOME/user_projects/domains/bi/bitools/bin/stop.sh
Run the following command to enable SSL on WebLogic internal channels and internal components:
ORACLE_HOME/user_projects/domains/bi/bitools/bin/ssl.sh internalssl true
(Optional) Configure advanced options by editing the file:
ORACLE_HOME/user_projects/domains/bi/config/fmwconfig/biconfig/core/ssl/bi-ssl.xml
Options supported are:
Enable server checking of client certificates.
Specify cipher suite to use.
For more information, see "Manually Configuring SSL Cipher Suite".
Restart the domain and BI component processes using:
ORACLE_HOME/user_projects/domains/bi/bitools/bin/start.sh
Confirm setup as follows:
Check WebLogic certificates and corresponding trust have been correctly configured using:
ORACLE_HOME/user_projects/domains/bi/bitools/bin/ssl.sh report
This command checks that WebLogic certificates and corresponding trust are correctly configured.
Confirm you can login to Analytics at:
https://<host>:<SecureManagedServerPort>/analytics
This confirms the HTTPs listener is enabled on each server, before you enable end-to-end SSL. Note that any communication between internal components is encrypted, but is only verifiable using 'ssl.sh report' command, or by checking server traffic.
Post conditions:
WebLogic servers:
Have https listener enabled on internal channels.
The external port configuration is unaltered. See "Enabling End-to-End SSL" for how to enable SSL on the external ports as well.
There is a separate internal identity (key/certificate pair) for each listener address. The certificate has a common name matching the listening address, which is compatible with standard https practice. The certificates are signed by the internal certificate authority.
System components (other than Essbase Studio):
Have https listener enabled on internal channels.
The external port configuration is unaltered. See "Enabling End-to-End SSL" for how to enable SSL on the external ports as well.
There is a separate internal identity (key or certificate pair) for each listener address. The certificate has a common name matching the listening address, which is compatible with standard https practice. The certificates are signed by the internal certificate authority.
Essbase Studio:
No change. Continues with existing connectivity.
This section describes how to disable SSL on internal communication links.
To disable BIEE internal SSL:
You must run commands from the master host. Oracle Business Intelligence must have been configured by the BI configuration assistant, WebLogic managed servers must have been created, and any scaling out must be complete.
Stop the system using:
<DomainHome>/bitools/bin/stop.sh
Run the following command to enable SSL on WebLogic internal channels and internal components:
<DomainHome>/ bitools/bin/ssl.sh internalssl false
Restart the domain using:
<OracleHome>/bi/bin/start.sh
Post conditions:
WebLogic servers:
Have https listener disabled on internal channels.
The external port configuration is unaltered.
System components (other than Essbase Studio):
Only listens on non SSL. SSL connections are not accepted.
Essbase Studio:
No change. Continues with existing connectivity.
You can provide the keys and certificates required to allow Oracle BI EE clients (for example the Administration Tool, and Job Manager) to connect to SSL-enabled servers.
Assumptions:
You run commands from master host.
You can complete this operation online and offline.
Prerequisites
Certificates are created using either the configuration assistant or by running ./ssl.sh regenerate command.
SSL on WebLogic is enabled (Section 5.2.2, "Configuring WebLogic SSL").
The system can be stopped or running.
To export trust and identity for clients:
Use the following command to export client identity and trust to 'mydir':
./ssl.sh exportclientcerts mydir
Note certificates and zip file are generated.
Mydir contains zip file clientcerts.zip
Mydir also contains expanded content of the zip file for immediate use:
clientcert.pem
clientkey.pem
identity.jks
internaltrust.jks
internaltrust/internalca.pem
internaltrust/<hashed form of above>
java clients such as Job Manager can successfully connect with secure option 'verify server certificate' set using identity.jks to define identity, and internaltrust.jks for their trust.
openssl clients such as the Administration Tool can successfully connect with secure option 'verify peer' set using clientcert.pem and clientkey.pem to define their identity, and internalca.pem as the trust file.
Clients accessing the BIEE components must be configured to use BIEE certificates.
Note:
First you must export the certificates by running the following command:<DomainHome>/bitools/bin/ssl.sh exportclientcerts <exportDir>
This section explains how to configure SSL for clients, and contains the following topics:
Section 5.6.2, "Using SASchInvoke when BI Scheduler is SSL-Enabled"
Section 5.6.4, "Enabling the Online Catalog Manager to Connect"
Section 5.6.5, "Configuring the Oracle BI Administration Tool to Communicate Over SSL"
Section 5.6.6, "Configuring an ODBC DSN for Remote Client Access"
Section 5.6.7, "Configuring Oracle BI Publisher to Communicate Over SSL"
Section 5.14.2, "Configuring SSL when Using Multiple Authenticators"
First you must export the client certificates.
To export the client certificates:
Run the following command:
<DomainHome>/bitools/bin/ssl.sh exportclientcerts <exportDir>
When prompted enter a new passphrase.
The passphrase is used to protect the export certificates. You must remember this passphrase for use when configuring each client.
The command exports Java keystores for use by Java clients, and individual certificate files for use non Java clients. To make moving the certificates to a remote machine more convenient, the export also packages all the files into a single zip file.
When the BI Scheduler is enabled for communication over SSL, you can invoke the BI Scheduler using the SASchInvoke command line utility.
To invoke the BI Scheduler when SSL-enabled using the SASchInvoke utility:
Create a new text file containing on a single line the passphrase you used when running the ./ssl.sh exportclientcerts command (see Section 5.6.1, "Exporting Client Certificates").
Ensure this file has appropriately restrictive file permissions to protect it. Typically it should only be readable by the owner.
Use the following syntax to run the SASchInvoke command:
SASchInvoke -u <Admin Name> (-j <job id> | -i <iBot path>) [-m <machine name>[:<port>]] [(-r <replace parameter filename> | -a <append parameter filename>)] [-l [ -c <SSL certificate filename> -k <SSL certificate private key filename> [ -w <SSL passphrase> | -q <passphrase file> | -y ]] [-h <SSL cipher list>] [-v [-e <SSL verification depth>] [-d <CA certificate directory>] [-f <CA certificate file>] [-t <SSL trusted peer DNs>] ] ] where: SSL certificate filename = clientcert.pem SSL certificate private key filename = clientkey.prm passphrase file = location of the passphrase file created above.
The command prompts you to enter the administrator password.
Enter the administrator password to start BI Scheduler.
To successfully connect to BI Scheduler that has been enabled for SSL, Oracle BI Job Manager must also be configured to communicate over SSL.
Oracle BI Job Manager is a Java based component and the keys and certificates that it uses must be stored in a Java keystore database.
Use this procedure to configure Oracle BI Job Manager to communicate with the BI Scheduler server over SSL.
To configure Oracle BI Job Manager:
From the File menu, select Oracle BI Job Manager, then select Open Scheduler Connection.
In the Secure Socket Layer section of the dialog box, select the SSL check box.
If the server setting 'verify client certificates' is false (one way SSL) then you can leave Key Store and Key Store Password blank. This is the default setting.
If the server setting 'verify client certificates' is true (two way SSL) then you must set Key Store and Key Store Password as follows:
Key Store=<exportclientcerts_directory>\identity.jks
Key Store Password = passphrase entered in Section 5.6.1, "Exporting Client Certificates".
To provide a secure link you should tick the verify server certificate. Without verification the connection will still work, but a person in the middle attack which impersonates the server will not be detected.
Select the Verify Server Certificate check box. When this is checked, the trust store file must be specified. This trust store contains the CA that verifies the Scheduler server certificate.
In the Trust Store text box, set the trust store to:
<exportclientcerts_directory>\internaltrust.jks
Set the Trust Store Password to the passphrase entered in Section 5.6.1, "Exporting Client Certificates".
The online Catalog Manager might fail to connect to Oracle BI Presentation Services when the HTTP web server for Oracle Business Intelligence is enabled for SSL. You must import the SSL server certificate or CA certificate from the web server into the Java Keystore of the JVM that is specified by the system JAVA_HOME variable.
To enable the online Catalog Manager to connect:
Navigate to Java's default trust store located at ORACLE_HOME/JAVA_HOME/ jre/lib/security.
The default trust store is named cacerts.
Copy the certificate exported from the web server to the same location as Java's default truststore.
Execute the command to import the certificate to the default truststore:
keytool -importcert -trustcacerts -alias bicert -file $WebServerCertFilename -keystore cacerts -storetype JKS
where the web server certificate file $WebserverCertFilename is imported into Java's default trust store named cacerts under an alias of bicert.
For example if using the Oracle WebLogic Server default demonstration certificate, then use the full path to the certificate located in ORACLE_HOME/wlserver/server/lib/CertGenCA.der.
Note:
The default password for the Java trust store is "changeit".Restart Catalog Manager.
Note:
You must start Catalog Manager using the secure HTTPS URL.To successfully connect to a BI Server that has been enabled for SSL, the Administration Tool must also be configured to communicate over SSL. The DSN for the Oracle BI Server data source is required.
To configure the Administration Tool to communicate over SSL:
Determine the Oracle BI Server data source DSN being used by logging into the Presentation Services Administration page as an administrative user.
For more information, see Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
Locate the Oracle BI Server Data Source field in the upper left corner. The DSN is listed in the following format: coreapplication_OH<DSNnumber>.
In the Administration Tool, enter the DSN name by selecting File, then Open, then Online. Select the DSN from the list.
Enter the repository user name and password.
The Administration Tool is now connected to the BI Server using SSL.
You can create an ODBC DSN for the Oracle BI Server to enable remote client access. For more information about how to enable SSL communication for an ODBC DSN, see "Integrating Other Clients with Oracle Business Intelligence" in Oracle Fusion Middleware Integrator's Guide for Oracle Business Intelligence Enterprise Edition.
You can configure BI Publisher to communicate securely over the internet using SSL. For more information, see "Configuring BI Publisher for Secure Socket Layer (SSL) Communication" in the Oracle Fusion Middleware Administrator's Guide for Oracle Business Intelligence Publisher.
If BI Publisher does not work after configuring SSL, you might need to reconfigure the HTTPs protocol, and SSL Port. For more information, see "Configuring Integration with Oracle BI Presentation Services" in the Oracle Fusion Middleware Administrator's Guide for Oracle Business Intelligence Publisher.
This task provides a warning if certificates are expired or about to expire.
You must run commands from the master host. The system can be running or stopped.
To check certificate expiry:
Run the following command to check certificate expiry:
<DomainHome>/ bitools/bin/ssl.sh expiry
Post conditions:
Detailed expiry information on certificate authority and server certificates is listed.
The ssl.sh command returns the following status:
13 – if certificates expired.
14 – if certificates are due to expire in less than 30 days.
0 – if certificates have more than 30 days life remaining.
Certificate replacement allows replacement of all certificates by new ones. You may want to do this because:
The existing certificates have expired, or are about to expire.
Both server certificates and CA (trust) certificates have defined lifespans. Once they expire connections using those certificates will no longer work.
Your organization has a policy requiring a different certificate expiry from the default provided by the BI configuration assistant.
The security of the existing certificates and keys has been compromised.
Assumptions:
You run commands from the master host.
This is an offline operation.
To replace the certificates:
Replace internal BIEE or client certificates.
When you use the regenerate command, it invalidates existing client certificates so you must re-export them.
./ssl.sh regenerate ./ssl.sh exportclientcerts mydir
Restart the domain using:
./start.sh
Check WebLogic certificates and corresponding trust are correctly configured using:
./ssl.sh report
The domain now runs with SSL, and uses the new certificates. Servers will not connect to a WebLogic instance using the old trust.
You can run the ssl.sh expiry command to list the new certificates with the new expiry date.
You can update certificates following a change of listener address, for example by setting an explicit listener address in WebLogic console to replace the default (blank). The ssl.sh scan command shows errors due to incorrect certificate common names. Connections to servers whose certificates do not match their listening addresses will be rejected.
Assumptions:
You run commands from the master host.
This is an offline operation.
To update the certificates after changing listening addresses:
Update certificates by running:
./ssl.sh rebindchannelcerts
Restart the domain using:
./start.sh
Check WebLogic certificates and corresponding trust are correctly configured using:
./ssl.sh report
The domain now runs with SSL, and uses the new certificates. The new certificates have the same expiry as existing certificates. The certificates are signed by the existing internal certificate authority so previously exported client trust remains valid.
You can run the ssl.sh expiry command to list the new certificates with the new expiry date.
This task provides the same internal SSL configuration for a new server.
Assumptions:
You run commands from the master host.
This is an offline operation.
One or more new servers have been created, either by cloning an existing server or creating from scratch.
To add a new server:
For each new server run:
./ssl.sh channel <new_bi_server> <port>
Alternatively you can repeatedly run:
./ssl.sh internalssl true
Then run the channel command as indicated in the internalssl command's error message.
Restart the domain using:
./start.sh
Check WebLogic certificates and corresponding trust are correctly configured using:
./ssl.sh report
The domain now runs with SSL, with all WebLogic managed servers using the internal SSL. If the servers were cloned, the cloned internal channel port has been replaced by the port given by the channel command. If the servers were created from scratch the internal channel has been created and configured to use SSL.
This task enables you to scale out a system which already has internal SSL enabled.
For information, see in "Adding New Computers" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition, where the necessary ssl.sh bindchannelcerts call is made.
This task provides the same SSL internal channel configuration as provided by the BI configuration assistant for systems configured using WLST or by direct application of configuration templates in the WebLogic configuration assistant.
Assumptions:
You run commands from the master host.
This is an offline operation.
To enable SSL in a configuration template configured system:
Run the following commands:
<domain_home>/bitools/bin/ssl.sh regenerate <days> <domain_home>/bitools/bin/ssl.sh targetapps bi_cluster
For each new server run:
./ssl.sh channel <new_bi_server> <port>
Alternatively you can repeatedly run:
./ssl.sh internalssl true
Then run the channel command as indicated in the internalssl command's error message.
Restart the domain using:
./start.sh
Check WebLogic certificates and corresponding trust are correctly configured using:
./ssl.sh report
The domain now runs with SSL, with all WebLogic managed servers using the internal SSL.
The default SSL configuration uses default cipher suite negotiation. You can configure the system to use a different cipher suite if your organization's security standards do not allow for the default choice. You can view the default choice in the output from the SSL status report.
This advanced option involves editing a configuration file. Be careful to observe the syntactic conventions of this file type.
A manually configured SSL environment can co-exist with a default SSL configuration.
To manually configure SSL cipher suite:
Configure SSL.
Select the desired Java Cipher Suite name from the options located at https://download.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#AppA">>https://download.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#AppA.
Create an Open SSL Cipher Suite Name that matches the cipher suite chosen, using the list at http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT">>http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT.
For example, Java Cipher Suite name SSL_RSA_WITH_RC4_128_SHA maps to Open SSL: RSA+RC4+SHA.
Edit the bi-ssl.xml file located at:
<DOMAIN_HOME>/config/fmwconfig/core/ssl/bi-ssl.xml
and add following sub-element to the JavaHost/Listener/SSL element. For example:
<EnabledCipherSuites>SSL_RSA_WITH_RC4_128_SHA</EnabledCipherSuites>
Restart the Oracle Business Intelligence components using:
./start.sh
For more information, see "Starting and Stopping Oracle Business Intelligence System Components" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
This section contains the following topics:
Section 5.14.1, "Configuring SSL for the SMTP Server Using Fusion Middleware Control"
Section 5.14.2, "Configuring SSL when Using Multiple Authenticators"
You must obtain the SMTP server certificate to complete this task.
To configure SSL for the SMTP server using Fusion Middleware Control:
Login to Fusion Middleware Control.
For more information, see Section 1.6.2, "Using Oracle Fusion Middleware Control".
Go to the Business Intelligence Overview page.
Display the Mail tab of the Deployment page.
Click the Help button on the page to access the page-level help for its elements.
Lock the configuring by clicking Lock and Edit Configuration.
Complete the fields under Secure Socket Layer (SSL) as follows:
Connection Security: Select an option, other fields may become active afterward.
Specify CA certificate source: Select Directory or File.
CA certificate directory: Specify the directory containing CA certificates.
CA certificate file: Specify the file name for the CA certificate.
SSL certificate verification depth: Specify the verification level applied to the certificate.
SSL cipher list: Specify the list of ciphers matching the cipher suite name that the SMTP server supports. For example, RSA+RC4+SHA.
Click Apply, then Activate Changes.
If you are configuring multiple authenticators, and have configured an additional LDAP Authenticator to communicate over SSL (one-way SSL only), you need to put the corresponding LDAP server's root certificate in an additional keystore used by the virtualization (libOVD) functionality.
To configure SSL when using multiple authenticators:
Note:
Before completing this task, you must configure the custom property calledvirtualize (lower case), and set its value to true (for more information, see Section 3.4.6, "Configuring Identity Store Virtualization Using Fusion Middleware Control").Create the keystore:
Set environment variables ORACLE_HOME, WL_HOME and JAVA_HOME.
For example (on UNIX):
set ORACLE_HOME=orahome
set WL_HOME=orahome/wlserver
set JAVA_HOME=orahome/oracle_common/jdk
Set up the keystore by running libovdconfig.sh (on UNIX), or libovdconfig.bat (on Windows), using -createKeystore option.
For example, on UNIX, open a shell prompt and change the directory to <OracleHome>/oracle_common/bin. Then, run the following command (which prompts for the Oracle Business Intelligence administrator user name and password), for example:
./libovdconfig.sh -host <hostname> -port <Admin_Server_Port> -username <BI Admin User> -domainPath <OracleHome>/user_projects/domains/bi/config/fmwconfig/ovd/default/keystores -createKeystore
When prompted, enter the Oracle Business Intelligence administrator password, and the OVD Keystore password (a new password that will be used to secure a Keystore file), created by the libovdconfig.sh -createKeystore command.
Once this command runs, you should see two new credentials in the Credential Store and a new Keystore file called adapters.jks under <OracleHome>/user_projects/domains/bi/config/fmwconfig/ovd/default/keystores.
Export the root certificate from the LDAP directory (refer to your LDAP documentation on how to do this).
Import the root certificate to the libOVD keystore using the keytool command:
<OracleHome>/jdk/jre/bin/keytool -import -keystore <OracleHome>\user_projects/domains/bi/config/fmwconfig/ovd/default/keystores/adapters.jks -storepass <KeyStore password> -alias <alias of your choice> -file <Certificate filename>
Restart WebLogic Server and Oracle Business Intelligence processes.
For more information, see Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
The following WebLogic artifacts are reserved for BIEE internal use:
Virtual hosts:
bi_internal_virtualhost1
Channels (on each managed server):
bi_internal_channel1
This section explains how to enable BI Composer to launch from BI Answers when in an SSL environment, by manually updating a JMX MBean value using Fusion Middleware Control.
In a non SSL environment, integration between BI Answers and BI Composer works without additional configuration. However, in an SSL environment, you must manually change the protocol value from http to https for integration to work properly.
To enable BI Composer to launch in an SSL environment:
Log in to Fusion Middleware Control in an SSL-enabled environment.
Display the WebLogic Server menu, and choose the System MBean Browser option.
Open Application Defined MBeans, and expand the following items:
oracle.adf.share.connections > Server: bi_server1 > Application: bicomposer > ADFConnections > ADFConnections > BISoapConnection > bi-default
Select bi-default and change the value of attribute 13, Protocol as follows:
Replace the value http with the value https
Click Apply.