SSL OFFLOADING AT OHS LAYER

 As more and more workloads are moving to security has become more important than ever. SSL over http also know as https is used to encrypt data between client and server i.e., to secure data over wire. It became ubiquitous even for internal applications. Gone are those days doing business over plain http. Though plain is less pain (there is no need to configure and manage certificates), as system admin we need to well equipped with https to secure applications we are managing.

Encryption and decryption of data can happen at different layers in Oracle EDG topology which includes external LB, OHS and application layer. Each one have advantages and disadvantages.

  1. SSL Offloading at Load Balancer (LB) – LB does all the heavy lifting of SSL handshake and encryption and decryption. As LBs are separate hardware devices it has advantage of using LB hardware and save cpu cycles of application server. Configuration wise too it is most simple solution as SSL certificate configuration at LB is no brainer. The main disadvantage with this approach is that it exposes traffic between LB and application server.
  2. SSL Offloading at OHS – Here SSL handshake and encryption and decryption is done by OHS server. It has advantage of securing traffic between client and OHS but traffic between OHS and weblogic application server is still in plain text.
  3. End to End Encryption – In this method, end to end traffic is encrypted with the help of weblogic application server. The main advantage with this approach is that entire data flow between client and server is encrypted.

Let us go through the steps required to configure SSL termination/offloading at OHS in this blog post. The steps at a high level are:

  1. Generate SSL certificate and private key to be used in public key encryption.
  2. Add certificate and private key to a keystore(wallet) to be used by OHS.
  3. Configure OHS to use this keystore/wallet.

The detailed steps are as below. Make changes to parameter according to your setup:
1. Set environment variables:

export ORACLE_HOME=/u01/app/oracle/product/FMW/Oracle_Home
export PATH=$ORACLE_HOME/oracle_common/bin:$PATH
export JAVA_HOME=/u01/app/oracle/product/JAVA/jdk1.8.0_251

2. Create a temporary jks keystore and add private key which will later converted to wallet.

keytool -genkey -alias qa_ca_cert -keyalg RSA -keysize 2048 -sigalg SHA256withRSA -dname “CN=example.com,OU=ACME IT,O=ACME,L=London,ST=London,C=UK” -keypass myKeyPassword -keystore keystore.jks -storepass myStorePassword

3. Generate a Certificate Signing Request (CSR):
keytool -certreq -v -alias qa_ca_cert -file qa_server.csr -sigalg SHA256withRSA -keypass myKeyPassword -storepass myStorePassword -keystore keystore.jks

4. Extract Key private key from JKS:

i) Convert JKS to the PKCS12 format:
keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.p12 -deststoretype PKCS12 -srcalias qa_ca_cert -deststorepass myStorePassword -destkeypass myKeyPassword

ii) Export unencrypted private key
openssl pkcs12 -in keystore.p12 -nodes -nocerts -out key.pem

5. Generate Certificate from private key. Here we are self signing the certificate. If you are planning to get certificate signed by trusted CA this step is not required.

openssl x509 -req -sha256 -days 3650 -in qa_server.csr -signkey key.pem -out server.crt

6. Import the self signed server certificate/CA signed certificate into jks store:

keytool -import -v -alias qa_ca_cert -file server.crt -keystore keystore.jks

7. Convert the keystore to the wallet as OHS uses wallet as keystore:

mkdir {walletLocation}
cd {walletLocation}
orapki wallet create -wallet ./wallet -auto_login_only
orapki wallet jks_to_pkcs12 -wallet ./wallet -keystore wallet/keystore.jks -jkspwd myStorePassword

8. Change SSL directive in ORACLE_HOME/ohs/conf/ssl.conf to refere newly created wallet.

9. Repeat this process in all nodes and restart the OHS servers.

Comments

Post a Comment

Popular posts from this blog

HOW WE REDUCED SOA OSB PROVISIONING FROM 4 DAYS TO 4 HOURS

 In our organization, we’ve undertaken the task of upgrading both SOA and OSB from version 12.2.1.3 to 12.2.1.4. This involves an out-of-place migration approach, wherein we create a new environment and switch traffic during the cutover. As you know, this process typically requires several days we opt for manual provisioing. A very significant amount of automation work was previously accomplished for 12.2.1.3 by our predecessors. Despite these efforts, the process still used to take lot of time due to following factors: Bugs in existing automation. For example, SOA composite deployments is not stable which warrants lot of manual work Import of 10s of TLS Certificates into KSS Manual retiring and shutting down of services Monitoring setup Miscellaneous: Increasing Log file count, enabling GC logging, changing heap parameters, bash profile changes While our current automation initiatives have yielded substantial savings, we aimed to capitalize on this upgrade activity to enable end-t...
Read more

NOT ABLE TO START RABBITMQ CLUSTER: CANNOT DECLARE A QUEUE ‘~S’ ON NODE ‘~S’: ~255P

We have 7 node rabbitmq cluster and we are using sharding queues. We have shutdown all non prod rabbitmq nodes as part of VM patching. As it was non prod, we thought of shutting down all together instead of rolling patching. We couldn’t start the any of the rabbitmq post patching. All of nodes were failing to start with the below error: 2022-06-23 05:13:10.104845-07:00 [error] <0.647.0> “Cannot declare a queue ‘~s’ on node ‘~s’: ~255p”, 2022-06-23 05:13:10.104845-07:00 [error] <0.647.0> [“queue ‘sharding: shard.my.queue – rabbit@rabbit1’ in vhost ‘my_vhost'” This is a known issue in some old versions of rabbitmq. rabbitmq node fails to come up with above error. Work around for this is to disable sharding policy for the problematic sharding queue. It can be done either from command line or from rabbitmq admin page. It requires to connect a running node. But as all the nodes were down, we could not disable sharding policy. Luckily, rabbitmq allows disabling sharding pulgi...
Read more

SOA SUITE 12.2.1.4 INSTALLATION: GOT EXCEPTION WHEN AUTO CONFIGURING THE SCHEMA COMPONENT(S) WITH DATA OBTAINED FROM SHADOW TABLE

  We planned to do out of place upgrade from soa suite 12.2.1.3 to 12.2.1.4. As part of this, we planned to automate end to end provisioning. While executing domain configuration using ansible and python scripts, we got following error in domain creation step. Got exception when auto configuring the schema component(s) with data obtained from shadow table. Failed to build JDBC Connection object: com.oracle.cie.domain.script.jython.CommandExceptionHandler. exception. Quick internet search gave few solutions like deleting domain-registry.xml file, verifying dehydration store password supplied to script etc. But none of them helped. After trying several options, I thought I might have done some stupid error prior to domain creation step. To track down the issue, though of checking what getDatabaseDefaults actually doing. I tried to grep for the getDatabaseDefaults function call inside oracle home. But couldn’t find the source code for the python function. As a final resort, thought of...
Read more