Here are some guidelines about using custom or third party SSL certificates with the WebLogic Servers:

• The SSL certificate used by each WebLogic server (identity key, private key) must be issued to that server’s listen address. For example, if the server WLS_PROD1 listens in apphost1.example.com, the CN of its SSL certificate must be that hostname or wildcard name valid for that hostname.

• Oracle recommends using an identity keystore shared by all the servers in the same domain where you import all the private keys used by the different WebLogic servers each mapped to a different alias.

• Oracle recommends using a trust keystore shared by all the servers in the domain. You must import the Certificate Authority’s certificate (and intermediate and root CA if needed) into this trust keystore.

• You must specify the identity keystore, alias of the identity key and the trust keystore for each WebLogic server in the WebLogic domain’s configuration. Use WebLogic’s Remote Console to configure these SSL settings for each server.

• Start the WebLogic servers using the appropriate java options to point to the trusted keystore so that they can communicate with external SSL endpoints that use the Certificate Authorities included in such a trust store.

The following commands are useful to manage SSL certificates in WebLogic.

• Command to import an SSL certificate (a private key) into the identity keystore:

  Syntax

  
  WL_HOME/server/bin/setWLSEnv.sh
  
  java utils.ImportPrivateKey
        -certfile cert_file
        -keyfile private_key_file
        [-keyfilepass private_key_password]
        -keystore keystore
        -storepass storepass
        [-storetype storetype]
        -alias alias 
        [-keypass keypass]
  

  Example for a Certificate Issued to apphost1.example.com

  
  WL_HOME/server/bin/setWLSEnv.sh
  
  java utils.ImportPrivateKey \
  -certfile apphost1.example.com_cert.der \
  -keyfile apphost1.example.com_key.der \
  -keyfilepass keypassword \
  -storetype pkcs12 \
  -keystore CustomIdentityKeystore.pkcs12 \
  -storepass keystorepassword \
  -alias apphost1.example.com \
  -keypass keypassword
  

• Command to import an SSL certificate (a trusted certificate) into the trusted keystore:

  Syntax

  
  keytool -import -v -noprompt -trustcacerts \
  -alias <alias_for_trusted_cert> \
  -file <certificate>.der \
  -storetype <keystoretype> \
  -keystore <customTrustKeyStore> \
  -storepass <keystorepassword>
  
  

  Example for Importing a CA Certificate

  
  keytool -import -v -noprompt -trustcacerts \
  -alias example_ca_cert \
  -file example_ca_cert.der \
  -storetype pkcs12 \
  -keystore CustomTrustKeyStore.pkcs12 \
  -storepass keystorepassword
  

  Example of the Java Options for Servers to Load Custom Trust Keystore

  
  EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES}
        -Djavax.net.ssl.trustStore=/u01/oracle/config/keystores/CustomTrustKeyStore.pkcs12
        -Djavax.net.ssl.trustStorePassword=<keystorepassword>"
  export EXTRA_JAVA_PROPERTIES

Here are some guidelines to use your own SSL certificates in OHS:

• Each OHS virtual host using SSL must use a wallet that contains only one private key. This private key will be used as the OHS server’s SSL certificate. It must be issued to the hostname in which the virtual host listens (the hostname value in the “VirtualHost” directive). The private key can also include other hostnames such as Subject Alternative Name (SAN) names (for example, the value of the “ServerName” directive). The virtual host must include the SSLWallet directive pointing to this wallet.

• Different OHS virtual hosts can use the same SSLWallet (hence, the same private key), as long as they use the same hostname in the VirtualHost directive. The port can be different.

• OHS acts as a client when it connects to the WebLogic servers. Hence, it must trust the certificate authority that issued the WebLogic’s certificates. Use the directive WLSSLWallet in the mod_wl_ohs.conf file to point to the appropriate wallet that contains the WebLogic certificates’ CA cert.

• The frontend load balancer acts as a client when it connects to the OHS servers. It must trust the certificate authority that issued the certificates used by OHS. You must check your load balancer documentation to import the OHS’s CA as a trusted authority.

The following commands are useful to manage keys and wallets in OHS.

• Command to create a wallet for OHS (orapki):

  Syntax

  
  $WEB_ORACLE_HOME/bin/orapki wallet create \
  -wallet wallet \
  -auto_login_only

  Example

  
  $WEB_ORACLE_HOME/bin/orapki wallet create \
  -wallet /u02/oracle/config/keystores/orapki/ \
  -auto_login_only

• Command to add a private key to a wallet (orapki) from an identity keystore:

  Syntax

  
  $WEB_ORACLE_HOME/bin/orapki wallet jks_to_pkcs12 \
  -wallet wallet \
  -pwd pwd \
  -keystore keystore \
  -jkspwd keystorepassword 
  [-aliases [alias:alias..]]

  Example

  
  $WEB_ORACLE_HOME/bin/orapki wallet jks_to_pkcs12 \
  -wallet /u02/oracle/config/keystores/orapki/ \
  -keystore /u02/oracle/config/keystores/customIdentityKeyStore.pkcs12 \
  -jkspwd keystorepassword \
  -aliases ohshost1.example.com

• Command to add all the trusted keys to a wallet (orapki) from a trusted keystore:

  Example

  
  $WEB_ORACLE_HOME/bin/orapki wallet jks_to_pkcs12 \
  -wallet /u02/oracle/config/keystores/orapki/ \
  -keystore /u02/oracle/config/keystores/customTrustKeyStore.pkcs12 \
  -jkspwd password

• Command to list all the keys of a wallet (orapki):

  Example

  
  $WEB_ORACLE_HOME/bin/orapki wallet display \
  -wallet /u02/oracle/config/keystores/orapki/

Determining which installed FMW products and components utilize persistent stores can be done through the WebLogic Server Console in the Domain Structure navigation under DomainName > Services > Persistent Stores. The list indicates the name of the store, the store type (FileStore and JDBC), and the target of the store. The stores listed that pertain to MDS are outside the scope of this chapter and should not be considered.

• About JDBC Persistent Stores for JMS and TLOGs
  
• Performance Considerations for TLOGs and JMS Persistent Stores
  

• Recommendations for TLOGs and JMS Datasource Consolidation
  To accomplish data source consolidation and connection usage reduction, use a single connection pool for both JMS and TLOGs persistent stores.
• Roadmap for Configuring a JDBC Persistent Store for TLOGs
  The following topics describe how to configure a database-based persistent store for transaction logs.
• Roadmap for Configuring a JDBC Persistent Store for JMS
  The following topics describe how to configure a database-based persistent store for JMS.
• Creating a User and Tablespace for TLOGs
  Before you can create a database-based persistent store for transaction logs, you must create a user and tablespace in a supported database.
• Creating a User and Tablespace for JMS
  Before you can create a database-based persistent store for JMS, you must create a user and tablespace in a supported database.
• Creating GridLink Data Sources for TLOGs and JMS Stores
  Before you can configure database-based persistent stores for JMS and TLOGs, you must create two data sources: one for the TLOGs persistent store and one for the JMS persistent store.
• Assigning the TLOGs JDBC Store to the Managed Servers
  If you are going to accomplish data source consolidation, you will reuse the <PREFIX>_WLS tablespace and WLSRuntimeSchemaDataSource for the TLOG persistent store. Otherwise, ensure that you create the tablespace and user in the database, and you have created the datasource before you assign the TLOG store to each of the required Managed Servers.
• Creating a JDBC JMS Store
  After you create the JMS persistent store user and table space in the database, and after you create the data source for the JMS persistent store, you can then use the WebLogic Remote Console to create the store.
• Assigning the JMS JDBC store to the JMS Servers
  After you create the JMS tablespace and user in the database, create the JMS datasource, and create the JDBC store, then you can assign the JMS persistence store to each of the required JMS Servers.
• Creating the Required Tables for the JMS JDBC Store
  The final step in using a JDBC persistent store for JMS is to create the required JDBC store tables. Perform this task before you restart the Managed Servers in the domain.

1. Stop a new workload by pausing production for the JMS Server. You must do this activity for each JMS Server of the server that is affected in the operation:
   1. In the WebLogic Remote Console, open the Monitoring Tree.
   2. Navigate to Environment > Servers.
   3. In the server that you want to delete, navigate to the Services > Messaging > JMS Runtime > JMS Servers.
   4. Select the JMS Servers.
   5. Click Pause > Production.
2. Drain the messages from the destinations. To drain the JMS messages, you can let applications consume the pending messages. However, this task is application dependent and may take time. Hence, Oracle recommends you to export the messages of each destination. Verify which destinations have messages:
   1. In the WebLogic Remote Console, open the Monitoring Tree.
   2. Navigate to Environment > Servers.
   3. In the server that you want to delete, navigate to Services > Messaging > JMS Runtime > JMS Servers.
   4. For each JMS Server, look whether the destination members have current messages. Identify the destination name, its JMS Module and JMS Server.
   5. Repeat this activity for each JMS Server that is running in the server that you want to delete.
   • Drain messages from queues: For those queue destinations that have current messages:

     1. In the WebLogic Remote Console, open the Monitoring Tree.

     2. Navigate to Dashboards and click JMS Destinations dashboard.

     3. Select the queue that you want to export messages from.

     4. In the Messages tab, select Export > Export All and export the messages to a file. Make a note of the file name for later use.

     5. Delete the exported messages by using the Delete All option. This step is important to avoid message duplications.

   • Drain messages from topics

     Oracle recommends you to drain and import messages from topics only if they have a critical business impact. See Table 19-6 for details about the purpose and business impact for each topic. Only the loss of messages in the topic dist_EDNTopic_auto, used by EDN, has a business impact.

     Table 19-6 Details of the Purpose and Business Impact for Each Topic of a Component

     Component	JMS Module	JMS Topic Name	Purpose	Business Impact of Message Loss
     BPM	BPMJMSModule	dist_MeasurementTopic_auto	Used for publishing process metrics messages to the internal process star schema.	Low impact. Will affect some dashboard number appearing in the PCS workspace dashboards and BAM  dashboards based on the process star schema data object.
     BPM	BPMJMSModule	dist_PeopleQueryTopic_auto	Used for updating logical group memberships.	Low impact. The group membership will be recalculated based on a scheduler.
     SOA	SOAJMSModule	dist_B2BBroadcastTopic_auto	Used by B2B, messages are meant to be consumed immediately.	No impact.
     SOA	SOAJMSModule	dist_EDNTopic_auto	Used for EDN, contains event messages for applications.	Business impact. Applications that consume these EDN event messages will lose them.
     SOA	SOAJMSModule	dist_TenantTopic_auto	No longer used.	No impact.
     SOA	SOAJMSModule	dist_XmlSchemaChangeNotificationTopic_auto	No longer used.	No impact.
     Insight	ProcMonJMSModule	dist_ProcMonActivationTopic_auto	Used by Insight for lifecycle operations - for activating an insight model across different nodes of the cluster.	No impact.
     BAM	BAMJMSSystemResource	dist_oracle.beam.cqs.activedata_auto	Not used in production.	No impact.
     BAM	BAMJMSSystemResource	dist_oracle.beam.persistence.activedata_auto	Data change notifications sent from persistence to the continuous query processor in support of active-data queries.	Low impact. Message loss could only cause incorrect data to be displayed in the active-data dashboards. Refreshing the dashboards or restarting the active-query will restore the correct data.
     BAM	BAMJMSSystemResource	dist_oracle.beam.server.event.reportcache.changelist_auto	Data changes sent from the report cache to the active-data dashboards.
     BAM	BAMJMSSystemResource	dist_oracle.beam.server.metadatachange_auto	Metadata changes sent to the downstream listeners if artifacts (queries, views, dashboards) are modified.
     MFT	MFTJMSModule	dist_MFTSystemEventTopic_auto	Used for publishing events that require synch in all the nodes, such as activation of the listening source, adding the PGP key, Mbean property changes, and so on.	Low impact. These messages are very short lived and their frequency is low. If there is any message loss, a restart ensures that all nodes in sync.

     Follow these steps drain messages from the topics:

     1. In the WebLogic Remote Console, open the Monitoring Tree.

     2. Navigate to Dashboards and click the JMS Destinations dashboard.

     3. Select the topic that you want to delete and navigate to its Subscribers.

     4. Select the Durable Subscriber that has current messages and clickShow Messages.

     5. Click Export > Export All and export the messages to a file. Make a note of the file name for later use.

     6. Delete the exported messages from the subscriber by clicking Delete > Delete All. This step is important to avoid message duplications.

     7. Repeat the export process for any subscriber in the topic that has current messages.