Skip to content

Insight and analysis of technology and business strategy

Part Five: Deploying High Availability Applications in Oracle Cloud Infrastructure— SSL Certificates and Load Balancer Setup

This is the fifth in a series of blog posts that covers setting up the load balancer for a high available setup of Oracle Enterprise Manager 13.5 using Oracle Cloud Infrastructure’s resources.



This is the fifth of a six-part series on how to deploy a high available installation of OEM 13.5 using Oracle Cloud Infrastructure (OCI) services.

Details of previous posts:

  • First: Initial configuration of the OCI environment and the setup of a 2-Node RAC VM Database
  • Second: How to launch and configure the first application machine
  • Third: Setup of the Data Guard Standby DB, the shared storage area and the deployment of the second application machine.
  • Fourth: How to install and configure OEM 13.5 on the first application machine
  • Fifth: How to set up an OCI Load balancer
  • Sixth: How to install (extend) OEM 13.5 on the second host, then include it in the load balancer rotation

This post shows how to configure the Load Balancer and secure the Oracle Management Service as well as the Management Agents with our custom SSL Keys.

Generate the Load Balancer’s SSH Keys

Since we’ll be using a secured connection through HTTPS, we’ll need to create our own SSH certificates to allow such connections to flow through the Load Balancer.

To create the new certificate we’ll use the first application machine “vloemapp01”:

  • Using “ssh-keygen”, generate a RSA Key with a passphrase to make it even more secure.
    Note: You’ll have to enter this passphrase every time you use the RSA Key file:
[root@vloemapp01 ~]# ssh-keygen -b 2048 -t rsa -f OEM135_LB.key
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in OEM135_LB.key.
Your public key has been saved in
The key fingerprint is:
The key's randomart image is:
+---[RSA 2048]----+
|      ..o++.   oE|
|       o +X+    +|
|        * X.   o |
|       o +.   o .|
|      . A X. . ..|
|     . . = ..   +|
|    . . A   =. +o|
|     + . . + +oVB|
|    . o   . o.+AX|


  • Create a certificate signing request (CSR) for our new key using “openssl”
    Note: Be sure to enter the Fully Qualified Domain Name (FQDN) of your Load Balancer in the “Common Name” field:
[root@vloemapp01 ~]# openssl req -new -key OEM135_LB.key -out OEM135_LB.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [XX]:US
State or Province Name (full name) []:ASHBURN
Locality Name (eg, city) [Default City]:ASHBURN
Organization Name (eg, company) [Default Company Ltd]:OEM
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:


  • Generate a self-signed certificate:
[root@vloemapp01 ~]# openssl x509 -req -days 365 -in OEM135_LB.csr -signkey OEM135_LB.key -out OEM135_LB.crt
Signature ok
Getting Private key
[root@vloemapp01 ~]# openssl x509 -in OEM135_LB.crt -noout -text
        Version: 1 (0x0)
        Serial Number:
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=ASHBURN, L=ASHBURN, O=OEM,
            Not Before: Jul 29 00:56:30 2021 GMT
            Not After : Jul 29 00:56:30 2022 GMT
        Subject: C=US, ST=ASHBURN, L=ASHBURN, O=OEM,
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha256WithRSAEncryption


  • And finally convert the self-signed certificate to PEM format:
[root@vloemapp01 ~]# openssl x509 -in OEM135_LB.crt -out OEM135_LB.pem -outform PEM


  • Just for your information, you can check the certificate in use by OEM with:
[oracle@vloemapp01 ~]$ emctl secdiag openurl -url https://vloemapp01:4903/empbs/upload


  • And you can also use “emctl” to dump the certificates in a file if you need to troubleshoot an issue:
[oracle@vloemapp01 ~]$ emctl secdiag dumpcertsinfile -file /tmp/customca.txt

Create a DNS Private View and register your Load Balancer

The agents must communicate with the management service through the load balancer, so the latter must be properly registered in your DNS.

The VNC’s subnet DNS does not allow changes, so you’ll need to create a new DNS Private View first.

  • Go to “Networking -> DNS Management -> Private Views” and click on “OEM-VCN” view:

  • Then click the “Create Zone” button:

  • Fill in the details and click the “Create” button:

  • After creating the new view, access its details then click the “Add record” button:

  • Fill in the record type, “A – IPv4 Address”, the host name, oem135slb01, its IP address, the TTL time, 30 seconds and click the “Submit” button:

  • Next, click the “Publish changes” button:

  • Confirm the changes by clicking the “Publish Changes” button again:

  • Add your newly created domain in the “Search” field of /etc/resolv.conf of both application machines and make sure the name server matches the IP of the server displayed in your console:
  • [root@vloemapp01 ~]# ping
    PING ( 56(84) bytes of data.
    64 bytes from ( icmp_seq=1 ttl=64 time=0.154 ms
    --- ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 0.154/0.154/0.154/0.000 ms
    [root@vloemapp01 ~]#  cat /etc/resolv.conf


  • The “resolv.conf” file might be automatically updated after a reboot. To prevent this, execute the following command:
    -- Set PRESERVE_HOSTINFO to 2 on /etc/oci-hostname.conf
    [root@vloemapp01 ~]# cat /etc/oci-hostname.conf
    # This configuration file controls the hostname persistence behavior for Oracle Linux
    # compute instance on Oracle Cloud Infrastructure (formerly Baremetal Cloud Services)
    # Set PRESERVE_HOSTINFO to one of the following values
    #   0 -- default behavior to update hostname, /etc/hosts and /etc/resolv.conf to
    #        reflect the hostname set during instance creation from the metadata service
    #   1 -- preserve user configured hostname across reboots; update /etc/hosts and
    #           /etc/resolv.conf from the metadata service
    #   2 -- preserve user configured hostname across instance reboots; no custom
    #        changes to /etc/hosts and /etc/resolv.conf from the metadata service,
    #        but dhclient will still overwrite /etc/resolv.conf
    #   3 -- preserve hostname and /etc/hosts entries across instance reboots;
    #        update /etc/resolv.conf from instance metadata service
    -- Set an immutable attribute to /etc/resolv.conf using "chattr":
    [root@vloemapp01 ~]# chattr -R +i /etc/resolv.conf


Security list details

  • Added required Ingress and Egress rules to allow the Management Service to communicate with the agents on all the hosts:

Creating the load balancer

The load balancer is fundamental in ensuring high availability; it controls and balances traffic between clients and the Oracle Management Service (OMS).

All communication with the Oracle Enterprise Manager goes through the load balancer.

After creating the load balancer we’ll have to set up the following:

  • Listeners: responsible for receiving incoming connections, then balancing it across the backend servers in the set.
  • Backend sets: Set of backend servers configured to service incoming connections. The set also includes monitoring rules to detect which servers are online.

Besides the load balancer, we need at least two application servers to ensure high availability for our enterprise manager.

  • To create your load balancer, go to “Load Balancers” under “Networking” and click “Create Load Balancer”:
  • Select “Load Balancer” as shown below:

  • Next, add the basic details for the Load Balancer, such as name and visibility type, then select the Public IP reserved previously:


  • Select the Virtual Cloud Network and its public sub-net, as well as the security group used to control traffic:

Note: As this is just a test, I’ve created a group named FULL which allows full traffic both ways. In an actual deployment, you’d create more restrictive groups to prevent unauthorized access.

  • Add the first backend server; these servers will handle incoming connections.
  • To achieve high availability, we must have one Backend Set containing at least two backend servers for each service in our application. At this point, we only have one OMS server, so we’ll add another backend server in the next post:

Include the public, private and signed certificates generated previously. This is a self-signed certificate, therefore both the public and signed ones are identical. Click “Next”:

  • Configure the HTTPS Console listener and include the same certificates used in the backend set:

  • Enable logging for your load balancer and click the “Submit” button:

  • If everything went as expected, you should see your new load balancer after a few minutes:


Adjust the existing backend set and listener

Now that the load balancer is up and running with the HTTPS Console backend set and listener configured, we need to adjust some advanced settings on both.

  • On the “Backend Sets” page, click on the the dots menu at the far right and select “Edit”:

  • Adjust the options according to the details below and click “Save Changes”:

Note: Set the expiration period carefully as a long one may cause delays and a short one can cause users to be re-routed while still actively working.

  • Check if the configurations of the listener are as follows, double check that the certificates match the ones used in the backend set and click “Save Changes”:

Note: Make sure that you have the correct certificate selected. We’ll use the same certificate on the listener as well to secure the management service and the agents so they can all communicate securely.

Create additional backend sets and listeners


  • Create another backend set to handle the HTTPS Upload port. Go to the “Backend Sets” section and click the “Create Backend Set” button:


  • Enter the backend set name, select the traffic distribution policy, mark the “Use SSL” checkbox and finally, select the same certificate used in the first set:

  • Enter the details for the Health Check policy for this particular backend set:
    Note: Health check policies are required to detect if the server is ready to receive connections. There should be no performance overhead as these are executed only once every 20 seconds.

  • Now create a listener to serve connections through the HTTPS Upload port 4903. Start by clicking the “Create Listener” button inside the “Listeners” section of your load balancer:


  • Enter the listener name, select the “HTTPS” protocol, port “4903” and the same certificates used in the backend set. Then, click on “Create Listener”:

Note: Make sure to select the same certificate used for the backend set.

Securing the Oracle Management Service

After setting up the load balancer, secure the Management Service using the same certificates in place at the load balancer.

  • Create a file named /home/oracle/customca.txt containing your public SSH key and its signature. The file should look something like this:
    -----END CERTIFICATE-----
    -----END CERTIFICATE-----


  • To allow OMS and the load balancer to communicate securely, re-secure OMS using the command below. Enter Sysman’s and the agent registration password when requested:
[oracle@vloemapp01 ~]$ emctl secure oms \
-host "" \
-secure_port 4903 \
-slb_port 4903 \
-slb_console_port 7803 \
-console \
-slb_jvmd_https_port 7803 \
-trust_certs_loc /tmp/customca.txt \
-lock_console \
Oracle Enterprise Manager Cloud Control 13c Release 5
Copyright (c) 1996, 2021 Oracle Corporation. All rights reserved.
Securing OMS... Started.
Enter Enterprise Manager Root (SYSMAN) Password :
Enter Agent Registration Password :
Securing OMS... Successful
Restart OMS


  • Restart OMS:
[oracle@vloemapp01 ~]$ emctl stop oms
Oracle Enterprise Manager Cloud Control 13c Release 5
Copyright (c) 1996, 2021 Oracle Corporation. All rights reserved.
Stopping Oracle Management Server...
Oracle Management Server Successfully Stopped
Oracle Management Server is Down
JVMD Engine is Down
[oracle@vloemapp01 ~]$ emctl start oms
Oracle Enterprise Manager Cloud Control 13c Release 5
Copyright (c) 1996, 2021 Oracle Corporation. All rights reserved.
Starting Oracle Management Server...
WebTier Successfully Started
Oracle Management Server Successfully Started
Oracle Management Server is Up
JVMD Engine is Up


Securing the Oracle Management Agents

Now that we secured the management server with the load balancer keys, you’ll need to secure the agents as well.

  • Log into the application machine and run the following command to re-secure the agent with the new keys:
[oracle@vloemapp01 ~]$ {AGENT_HOME}/bin/emctl secure agent -emdWalletSrcUrl
  • Repeat the above step to the Database machines and any other hosts that have OEM’s management agent installed.


Have you tried implementing your own load balancer setup? Share your questions or concerns in the comments and don’t forget to sign up for Part 6 here.

Top Categories

  • There are no suggestions because the search field is empty.

Tell us how we can help!