Configure Network Security

By default, an Oracle SOA Cloud Service instance is accessible only through secure protocols like SSL and SSH, and only using specific ports. But you’re able to customize the default security configuration to support different access rules and security policies.

To provide the highest level of network security, Oracle SOA Cloud Service implements an “access by exception” architecture. You must explicitly grant network access to your service instance for administrators, application users or other cloud services. Similarly, if you want your service instance to be accessible over a non-secure protocol like HTTP, you must change the default configuration.

About the Default Access Ports

To use Oracle resources through Oracle SOA Cloud Service, access them through the default ports.

Ports Available from Within the Oracle Cloud Network

Resource Protocol Default Port for Release 16.4.5 and Earlier Default Port for Release 17.1.3 and Later

Oracle WebLogic Server Administration Console

HTTP

7001

9071

Oracle Fusion Middleware Control

HTTP

7001

9071

Managed Server

HTTP

HTTPS

8001

8002

9073

9074

Database

SQL Net

1521

1521

Ports Available from Outside the Oracle Cloud Network

Resource Protocol Default Port

Oracle WebLogic Server Administration Console

HTTPS

7002

Oracle Fusion Middleware Control

HTTPS

7002

Oracle Traffic Director Administration Console

HTTPS

8989

End user applications when the load balancer is enabled

HTTP

HTTPS

80*

443

End user applications when the load balancer is disabled and there are multiple managed servers

HTTP

HTTPS

9073*

9074

End user applications when the load balancer is disabled and there is only one managed server

HTTP

HTTPS

80*

443

Service instance VM

SSH

22

Oracle Traffic Director VM

SSH

22

The diagram in About the Deployment Topology of Virtual Machines (Using Oracle Java Cloud Service) illustrates port allocation in an Oracle SOA Cloud Service VM deployment topology.

Note:

If a service instance is created with the Create New Oracle SOA Cloud Service Instance wizard, the HTTP port is disabled. You cannot enable the HTTP port for such a service instance through any of the interfaces to Oracle SOA Cloud Service, such as the Service Console or the REST API.

* For end user applications, the default ports depend on how the service instance was created:

If the service instance was created by using the Create New Oracle SOA Cloud Service Instance wizard, the default ports are as follows:

  • If a load balancer is enabled, the HTTP port is disabled and the HTTPS port is 443 by default.

  • If a load balancer is not present and the service instance contains more than one managed server, the HTTP port is disabled and the HTTPS port is 8002/9074.

  • If a load balancer is not present and the Oracle SOA Cloud Service instance contains only one managed server, the server ports are 443 for HTTPS and disabled for HTTP.

If the service instance was created by using the REST API, the default ports are as follows:

  • If a load balancer is present, the default ports for applications are 80 for HTTP and 443 for HTTPS. You can reconfigure these ports.

  • If a load balancer is not present and the Oracle SOA Cloud Service instance contains more than one managed server, the default ports are 8001/9073 for HTTP and 8002/9074 for HTTPS.

  • If a load balancer is not present and the Oracle SOA Cloud Service instance contains only one managed server, the managed server ports are set to 80 and 443 respectively. You can reconfigure these ports.

You can continue to use HTTPS port 8081 to access an application running on an existing service instance that was created by using the Create New Oracle SOA Cloud Service Instance wizard. In this case, HTTP port 8080 is disabled and you can no longer use this port to access your application.

For information about creating a service instance by using the REST API, see Create a Service Instance in Oracle Cloud REST API for Oracle SOA Cloud Service.

For information about how to reconfigure ports by using the REST API, see Updating the Default Access Ports When Creating a Service Instance Using the REST API in REST API for Oracle SOA Cloud Service.

Accessing Oracle SOA Cloud Service URLs Externally Using a Public IP Address

Oracle SOA Cloud Service URLs can be accessed externally using a public IP address. Use port 80 with the HTTP protocol and port 443 with the HTTPS protocol. This redirects access to port 8001. For example, to access the B2B console using HTTPS:

https://public_IP_address:443/b2bconsole

Manage Access Rules for an Oracle SOA Cloud Service Instance

Not Oracle Cloud Infrastructure This topic does not apply to Oracle Cloud Infrastructure.

Access rules enable you to control network access to the VMs that make up your Oracle SOA Cloud Service instance. Each rule has a source, a destination, a destination port and a transport protocol.

For example, you can create an access rule that enables:

  • A database VM to access a specific port on your Managed Server VMs

  • Public Internet access to a specific port on the Administration Server VM

Oracle SOA Cloud Service creates several default rules on a new service instance, such as public access to the Administration Server and load balancer VMs on port 22 (SSH). Some of these are system rules, which cannot be disabled. Do not modify or delete system generated access rules that are marked DO NOT MODIFY. For information about the default access ports in a service instance, see About the Default Access Ports.

Prior to creating an access rule, ensure that the destination VM is configured to listen on the chosen ports. For example, on VMs running Oracle WebLogic Server you can configure network channels to control the listen ports for your Administration Server and Managed Servers. Refer to these topics in Administering Server Environments for Oracle WebLogic Server:

Create a New Access Rule for a Service Instance

Not Oracle Cloud Infrastructure This topic does not apply to Oracle Cloud Infrastructure.

To control network access to the nodes in your Oracle SOA Cloud Service instance, you can define access rules.

Note:

If you provisioned this service instance in an Oracle Cloud Infrastructure region, see Security Lists in the Oracle Cloud Infrastructure Services documentation.

Use the following steps to create a new access rule for a service instance:

  1. Navigate to the Oracle SOA Cloud Service Console.
  2. Click the Menu icon Menu icon adjacent to the service instance name and select Access Rules.

    The Access Rules page is displayed, showing the list of all access rules.

  3. Click Create Rule.

    The Create Access Rule dialog is displayed.

  4. Specify a unique Rule Name. Optionally specify a rule Description.

    The name must begin with a letter, and can contain numbers, hyphens, or underscores. The length cannot exceed 50 characters. When you create a rule, you cannot use prefixes ora_ or sys_.

  5. Specify a Source for the rule:
    • PUBLIC-INTERNET — Any host on the internet
    • OTD — The Oracle Traffic Director load balancer VMs
    • WLS_ADMIN_SERVER — The WebLogic Server Administration Server VM
    • WLS_MANAGED_SERVER — The WebLogic Server Managed Server VMs
    • DB — The database specified when the Oracle Java Cloud Service instance was created. If your service instance is configured with more than one database, you can select which database to use for the source.
    • Custom — A custom list of addresses from which traffic should be allowed. In the field that displays below when you select this option, enter a comma-separated list of the subnets (in CIDR format, such as 192.123.42.1/24) or IPv4 addresses for which you want to permit access.
  6. Choose a Destination for the rule:
    • OTD — The Oracle Traffic Director load balancer VMs
    • WLS_ADMIN_SERVER — The WebLogic Server Administration Server VM
    • WLS_MANAGED_SERVER — The WebLogic Server Managed Server VMs

    The source and the destination must be different.

  7. Specify the Destination Port(s) through which the source will access the destination.

    You can specify a single port or a range of ports (such as 7001–8001).

  8. Specify the transport Protocol (TCP or UDP) with which the source will access the destination.
  9. Click Create.
  10. To manage the existing access rules on the Access Rules page, click the Menu icon Menu icon for a rule and choose an option:
    • Enable — Rules of type USER or DEFAULT can be enabled. Rules of type SYSTEM cannot.
    • Disable — Rules of type USER or DEFAULT can be disabled. Rules of type SYSTEM cannot.
    • Delete — Rules of type USER can be deleted. Rules of type DEFAULT or SYSTEM cannot.
  11. When you have finished using the Access Rules page, click the links at the top of the page to return to the Services tab or the Instance Overview page.

Enable or Disable an Access Rule

You can dynamically enable or disable existing access rules for an Oracle SOA Cloud Service instance.

Access rules control the network access to the nodes in your service instance, and to external access from the internet. When a service instance is provisioned, Oracle SOA Cloud Service defines several default access rules. You can enable or disable these rules to control access to specific port numbers on specific nodes. Make sure you consider the possible security implications before you open ports to external access.

  1. Access your service console.
  2. Beside the service that you want to modify, click Manage this instance Menu icon, and then select Access Rules.
  3. On the Access Rules page, beside the rule, click Actions Menu icon, and then select Enable or Disable.
    You can enable or disable USER and DEFAULT type rules. You cannot disable SYSTEM type rules.
  4. When prompted for confirmation, click Enable or Disable.

To return to either the Instances page or the Overview page for the selected service instance, click the locator links at the top of the page.

Delete an Access Rule

You can delete an access rule for an Oracle SOA Cloud Service instance.

Access rules control the network access to the nodes in your service instance, and to external access from the internet. Deleting a rule disables access to specific port numbers on specific nodes.

You can delete only user-created access rules. You cannot delete system-generated access rules.

You cannot modify the configuration of an existing access rule. You must delete the rule and recreate it.

  1. Access your service console.
  2. Beside the service that you want to modify, click Manage this instance Menu icon, and then select Access Rules.
  3. On the Access Rules page, beside the rule, click Actions Menu icon, and then select Delete.
    You can delete USER type rules. You cannot delete SYSTEM or DEFAULT type rules.
  4. When prompted for confirmation, click Delete.

To return to either the Instances page or the Overview page for the selected service instance, click the locator links at the top of the page.

Manage Access Rules for Instances in Oracle Cloud Infrastructure

Only Oracle Cloud Infrastructure This topic applies only to Oracle Cloud Infrastructure.

Access rules enable you to control network access to the VMs that make up your Oracle SOA Cloud Service instance. Each rule has a source, a destination, a destination port and a transport protocol.
Before you start creating an access rule in Oracle Cloud Infrastructure, gather the following details:
  • The region in which the pod is being provisioned such as us-ashburn-1 or us-phoenix-1

  • Oracle Cloud Infrastructure Console login details

    • Oracle Cloud Infrastructure login URL for example https://console.us-ashburn-1.oraclecloud.com

    • Cloud Tenant Name, for example, oic1

    • User ID and password

  • Compartment Name

To create an access rule in an Oracle Cloud Infrastructure instance:

  1. Navigate to the Oracle Cloud Infrastructure Console for example, https://console.us-ashburn-1.oraclecloud.com.
  2. Enter the Cloud Tenant name. For example oic1.
  3. Enter the User Name and Password.
  4. After you sign in, the Console Home page is displayed. Select Menu from the top left corner of the page.
  5. Select Compute, and then Instances.
  6. Select the compartment name from the list. For example MangedCompartmentForPaas.
    On the selected compartment, you will see available instances.
  7. Click your instance to view its details. In the instance details page, click the subnet link.
  8. In the list of subnets, locate the subnet your instance was created in and click any security list next to the subnet.
  9. On the Security Lists page, click Edit All Rules.
  10. Add an ingress rule for port 7522 by setting the values as shown below:
    • Source Type – CIDR

    • Source CIDR – 0.0.0.0/0

    • IP Protocol – TCP

    • Source Port Range – All

    • Destination Port Range - 7522

  11. Click Save Security List Rules to save the security rules.

    Note:

    See Security Lists in the Oracle Cloud Infrastructure Services documentation.

Enable HTTP Access to an Oracle SOA Cloud Service Instance

If you create an Oracle SOA Cloud Service instance by using the web console rather than the REST API, HTTPS access is enabled by default but HTTP access is disabled. You can enable HTTP access on the load balancer after you have created the service instance.

These instructions assume a load balancer has been enabled in your service instance. If there is no load balancer, you must instead create a network channel on all Managed Servers in your Oracle WebLogic Server domain. Refer to these topics in Administering Server Environments for Oracle WebLogic Server:

By default the load balancer in your service instance listens for HTTP traffic on port 8080. However, the load balancer VM automatically redirects incoming traffic on port 80 to port 8080.

Tasks:

Enable the HTTP Port on the Load Balancer

You must enable a port on the load balancer (Oracle Traffic Director) to accept HTTP traffic from the public Internet to your Oracle SOA Cloud Service instance.

Access to the Load Balancer Console is disabled by default.

  1. Navigate to the Services page of the Oracle SOA Cloud Service Console.
  2. Click menu icon for the desired service instance and select Open Load Balancer Console. Log in to console using the credentials defined when provisioning your service instance.

    If you created your service instance using the Oracle SOA Cloud Service console, the user name and password default to the Oracle WebLogic Server Administration Console user name and password.

    Access the load balancer configuration (for example, opc-config) and click the Target Navigation icon Target Navigation icon. Expand the Traffic Director folder and click the name of the Traffic Director configuration.

  3. Navigate to the Listeners in this configuration and click Traffic Director Configuration and select Administration > Listeners.
  4. Click http-listener-1.
  5. Select the Enabled checkbox.
  6. Click OK.
  7. click OK to activate your changes.

The next task is to create an access rule for the port on the load balancer.

Create an Access Rule for the HTTP Port

You must create an access rule to allow public access to the load balancer (Oracle Traffic Director) through the HTTP port.

If you provisioned this service instance in an Oracle Cloud Infrastructure region, instead you must use the Oracle Cloud Infrastructure Console to create the access rules (security list). See Security Lists in the Oracle Cloud Infrastructure Services documentation.

  1. Navigate to the Oracle SOA Cloud Service Console.
  2. Click the Menu icon Menu icon adjacent to the service instance name and select Access Rules.

    The Access Rules page is displayed, showing the list of all access rules.

  3. Click Create Rule.
    The Create Access Rule dialog is displayed.
  4. Specify a unique name for the access rule.

    The name must begin with a letter, and can contain numbers, hyphens, or underscores. The length cannot exceed 50 characters. You cannot use prefixes ora_ or sys_.

  5. Enter Permit public http to OTD server for the description.
  6. Select PUBLIC-INTERNET for the source.
  7. Select OTD for the destination.
  8. Enter 80 as the port and accept the default protocol (TCP).
  9. Click Create.
  10. Refresh the page periodically. The access rule will appear on the Access Rules table after it is created.

You can now access your application by using the default HTTP port:

http://<IP_of_load_balancer>/<context_root>

Enable Communication Between Oracle SOA Cloud Service Instances

The default access rules in an Oracle SOA Cloud Service instance only permit communication between Managed Server VMs and the database, and between Managed Server VMs and the load balancer (if enabled). Use custom access rules to enable communication between the Managed Servers of different service instances.

The architecture of a business application may span multiple tiers, where each application tier is a separate Oracle SOA Cloud Service instance. Similarly, certain integration features of Oracle WebLogic Server enable applications to easily communicate across multiple domains, such as Foreign JNDI Providers and Foreign JMS Servers. In these scenarios, you must use access rules to explicitly permit network communication between service instances.

Identify the host names of the VMs in your first service instance. The host names typically use the format domainName-wls-number.

For example, if your domain name is myjcs1 and this domain consists of 3 VMs, the VM host names would typically be:

  • myjcs1–wls-1

  • myjcs1–wls-2

  • myjcs1–wls-3

You can also refer to the Instance Overview page in the Oracle SOA Cloud Service Console. Locate the Host property of each VM.

Before you begin, use an SSH client to connect to the Administration Server VM of the first service instance. See Connect to an Administration Server or Load Balancer VM.

  1. From your SSH session on the Administration Server, use the nslookup command to identify the corresponding IP address of each host name.

    For example:

    nslookup myjcs1-wls-2
    
    Name:   myjcs1-wls-2.compute-myaccount.oraclecloud.internal
    Address: 10.11.12.13
    
  2. Access the Oracle SOA Cloud Service Console.
  3. Click the Menu icon Menu icon adjacent to your second service instance and select Access Rules.
    The Access Rules page is displayed, showing the list of all access rules.
  4. Click Create Rule.
    The Create Access Rule dialog is displayed.
  5. Specify a unique Rule Name, such as myjcs1–to-myjcs2.
  6. For Source, select the custom option. Enter a comma-separated list of the IP addresses for the first service instance.

    For example: 10.11.12.13,10.11.12.14,10.11.12.15

  7. Select WLS_MANAGED_SERVER for the Destination.
  8. Specify 8001 as the Destination Port.

    Note:

    If you customized your Managed Servers to listen on additional ports, you can specify them as a comma-separated list such as 8001,9001.
  9. Accept the default Protocol (TCP).
  10. Click Create.

Manage SSH Access for an Oracle SOA Cloud Service Instance

Use the SSH Access page to view and manage SSH keys for Oracle SOA Cloud Service instances in your identity domain.

For information on creating SSH keys see Generating a Secure Shell (SSH) Public/Private Key Pair.

If the SSH private key that you use to access a service instance becomes lost or corrupted, you can add a new public key to the service instance. You may also need to add a new public key to a service instance in order to comply with your organization’s security policies or regulations.

  1. From the Oracle SOA Cloud Service console click the SSH Access tab.
  2. Locate your service instance and click Add New Key.

For more information about using SSH with Oracle SOA Cloud Service, see Access a VM Through a Secure Shell (SSH).

Configure SSL for an Oracle SOA Cloud Service Instance

Secure Socket Layer (SSL) is the most commonly-used method of securing data sent across the internet, and assures visitors that transactions with your application are secure. You can configure SSL between the client browser and the load balancer in your Oracle SOA Cloud Service instance in order to ensure that applications are accessed securely.

By default SSL is already enabled within the software components of an Oracle SOA Cloud Service instance, including Oracle WebLogic Server and the load balancer. They are configured to use a self-signed SSL certificate that was generated by Oracle SOA Cloud Service. Clients will typically receive a message indicating that the signing CA for the certificate is unknown and not trusted.

Tasks:

Create a Self-Signed SSL Certificate in the Load Balancer

For development Oracle SOA Cloud Service environments, you can use either a CA-issued or a self-signed certificate. You can create a self-signed certificate using the Load Balancer Console.

To obtain and use a CA-issued certificate instead, see Import a CA-Issued SSL Certificate to the Load Balancer.

  1. Navigate to the Services page of the Oracle SOA Cloud Service console.
  2. Click menu icon for the desired service instance and select Open Load Balancer Console. Log in to console using the credentials defined when provisioning your service instance.

    If you created your service instance using the Oracle SOA Cloud Service console, the user name and password default to the Oracle WebLogic Server Administration Console user name and password.

    Access the load balancer configuration,(opc-config) by following the steps below:

    1. Once logged in the OTD console, click the Target Navigation icon.
    2. Expand Traffic Director folder.
    3. Click on Load Balancer configuration (opc-config).
  3. Perform these steps to create a self-signed certificate:
    1. Click Traffic Director Configuration and select Security > Manage Certificates.
    2. Click Generate Keypair.
    3. Enter an Alias for the new certificate.
    4. Set the Common Name to your custom domain name. For example, example.com.
    5. Complete the remaining fields and click OK.

Import a CA-Issued SSL Certificate to the Load Balancer

For production Oracle SOA Cloud Service environments, it is recommended that you use a CA-issued SSL certificate. A CA-issued SSL certificate reduces the chances of experiencing a man-in-the-middle attack.

There are multiple CA vendors in the marketplace today, each offering different levels of service at varying price points. Research and choose a CA vendor that meets your service-level and budget requirements.

For a CA vendor to issue you a CA-issued SSL certificate, you need to provide the following information:

  • Your custom domain name.

  • Public information associated with the domain confirming you as the owner.

  • Email address associated with the custom domain for verification.

Create a Certificate Signing Request (CSR) by using the Load Balancer Console and submit the CSR to the CA vendor. After receiving the CA-issued certificate, import it into the Load Balancer configuration by following the steps below:

  1. Navigate to the Services page of the Oracle SOA Cloud Service console.
  2. Click Menu icon for the desired service instance and select Open Load Balancer Console. Log in to console using the credentials defined when provisioning your service instance.

    If you created your service instance using the Oracle SOA Cloud Service console, the user name and password default to the Oracle WebLogic Server Administration Console user name and password.

    Access the load balancer configuration (opc-config) by following the steps below:
    1. Once logged in the OTD console, click the Target Navigation icon.
    2. Expand Traffic Director folder.
    3. Click on Load Balancer configuration (opc-config).
  3. Perform these steps to generate a CSR:
    1. Click Traffic Director Configuration and select Security > Manage Certificates.
    2. Click Generate Keypair.
    3. Enter an Alias for the new certificate.
    4. Set the Common Name to your custom domain name. For example, example.com.
    5. Complete the remaining fields and click OK.
    6. Select your new certificate and click Generate CSR.
  4. Save the generated CSR text, including the header line -----BEGIN NEW CERTIFICATE REQUEST----- and footer line -----END NEW CERTIFICATE REQUEST-----.

    For example:

    -----BEGIN NEW CERTIFICATE REQUEST-----
    MIIC9jCCAd4CAQAwYDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMQwwCgYDVQQH
    EwNTQ0ExDzANBgNVBAoTBk9yYWNsZTEPMA0GA1UECxMGT3JhY2xlMRQwEgYDVQQD
    I+XY7ByYRma1XlM1cYoMUiKSnRHdllUZMRwYHu4AZvrEMIhKjB6YiC0F
    -----END NEW CERTIFICATE REQUEST-----
    

    The CSR includes the public key and other information that the CA vendor needs to verify the identity of the load balancer server.

  5. Submit the CSR to your CA vendor to request a new CA-issued SSL certificate.

    For more information about submitting the CSR, refer to your CA vendor documentation.

    Your CA vendor uses the CSR information to validate the domain and provides you with a valid SSL certificate, typically via email.

  6. Return to the Load Balancer Console for your service instance.
  7. Perform these steps to import the CA-issued certificate:
    1. Click Traffic Director Configuration and select Security > Manage Certificates.
    2. Click Import.
    3. Verify that Certificate Type is set to Certificate.
    4. Select the Alias of the certificate you generated earlier.
    5. You can paste the certificate text directly in the Paste Certificate String Here field, or click Choose File and select the certificate on your local file system. If you opt to paste the certificate text, be sure to include the headers BEGIN CERTIFICATE and END CERTIFICATE, including the beginning and ending hyphens.
    6. Click OK.

For more information about managing load balancer certificates, see:

Associate the SSL Certificate With the Load Balancer

After installing a CA-issued or self-signed SSL certificate to the load balancer, you must associate it with the HTTPS listeners in the load balancer’s configuration. After the association is made, the load balancer will present the SSL certificate while processing any new HTTPS requests.

  1. Navigate to the Services page of the Oracle SOA Cloud Service console.
  2. Click menu icon for the desired service instance and select Open Load Balancer Console. Log in to console using the credentials defined when provisioning your service instance.

    If you created your service instance using the Oracle SOA Cloud Service console, the user name and password default to the Oracle WebLogic Server Administration Console user name and password.

    Access the load balancer configuration (opc-config) by following the steps below:

    1. Once logged in the OTD console, click on the Target Navigation icon.

    2. Expand Traffic Director folder.

    3. Click on Load Balancer configuration (opc-config).

  3. Click Traffic Director Configuration and select Administration > Listeners to navigate to the Listeners in this configuration.
  4. Click https-listener-1.
  5. In the SSL/TLS Settings section select your new certificate in the RSA Certificate field.
  6. Click OK to activate your changes:
  7. Repeat from step 3 to update the certificate of any additional HTTPS listeners in this configuration.

    Alternatively, you can configure SSL/TLS Settings for an entire Virtual Server in the load balancer configuration.

After modifying a listener’s certificate you must also restart the load balancer node(s) in your service instance for the change to take effect. See Stop, Start, and Restart Managed Server and Load Balancer VMs.

For more information about the SSL settings of the load balancer, see Configuring SSL/TLS Between Oracle Traffic Director and Clients in Administering Oracle Traffic Director.

Set up Oracle SOA Cloud Service to Use CA-Verified SSL Certificates (non-OTD)

This section explains the steps for replacing the identity and trust of Oracle SOA Cloud Service with custom identity and custom trust and register the Oracle SOA Cloud Service server with digital certificates procured from public certificate authorities like digicert or any other third party authority.

As a pre-requisite, register Oracle SOA Cloud Service domain with the public DNS for CA verification. For the documentation purpose, the public IP of Oracle SOA Cloud Service domain is registered with mydomain.com and taken the CA signed certificates from mydomain

The Enterprise Manager (EM) console needs to be accessible using the public domain name.

Note:

The steps mentioned here are for Oracle SOA Cloud Service instance not using OTD. If you are using OTD, see Import a CA-Issued SSL Certificate to the Load Balancer.
Register Domain Name for Oracle SOA Cloud Service

Register a domain for Oracle SOA Cloud Service server with a public DNS server. The public DNS server used in the documentation is mydomain.com.

  1. Register a domain for Oracle SOA Cloud Service server with public DNS server. You can register your domain with any public DNS Server of your choice mapping it to your public IP of Oracle SOA Cloud Service.
    For example register soacs.oraclecloud.co.in domain in mydomain.com, mapping to the public IP of Oracle SOA Cloud Service server.
  2. Test access to the Enterprise Manager (EM) console and the WebLogic console through the domain name registered.
Create Custom Identity and Custom Trust Keystore and Generate CSR

Create custom identity and custom trust keystore and generate Certificate Signing Request (CSR).

To create custom identity and custom trust keystore and generate CSR:
  1. Login to the Enterprise Manager (EM) console and access the Keystores page by opening Weblogic domain > Security > Keystore.   
  2. Under the system stripe, create a new keystore by clicking the Create Keystore button.
  3. Provide the following details for custom identity:
    1. Keystore Name: custIdentity
    2. Protection: Select the Password option.
    3. Keystore Password: Enter the password.
    4. Confirm Password: Confirm the password.
  4. Create another new keystore by clicking the Create Keystore button.
  5. Provide the following details for custom trust:
    1. Keystore Name: custTrust
    2. Protection: Select the Password option.
    3. Keystore Password: Enter the password.
    4. Confirm Password: Confirm the password.
  6. Click Manage on the custIdentity keystore name, click Generate Keypair to create a new key pair, provide the following details: inside custIdentitywith alias as custIdentity and password as required.
    1. Alias Name: custIdentity
    2. Common Name: Common name, for example, soacs.mydomain.com (domain name registered with public DNS)
    3. Oraganizational Unit: Name of the organizational unit
    4. Organization: Organization name
    5. Enter City, State, and Country names
    6. Key Type: RSA
    7. Key Size: 2048
    8. Click OK to generate the keypair.
  7. Select the newly created keypair and click Generate CSR.
  8. Export the created CSR, share it with Certificate Authority, such as digicert CA, and get root, intermediate, and signed certificates.

    The certificate is generated for the domain name you used in the Common Name field.

  9. Download the certificates shared in the zip file from CA.
    It is not mandatory to create identity and trust keystore under system stripe that comes with Oracle SOA Cloud Service provisioning by default. You can create a new custom stripe and create identity and trust keystores under it.
Share the CSR with CA to get CA-Signed Certificates

  1. Select the new keypair created above under the custIdentity and click Generate CSR.
  2. Export the created CSR and share it with the Certificate Authority and get root, intermediate, and signed certificates. The certificate is generated for the domain name you used in the Common Name field.
  3. Download the certificates shared in the zip file from the CA.
    The zip file contains:
    • either the three certificates individually - root, intermediate, and signed certificates
    • or two certificates root and intermediate in one chain and signed certificate separately
  4. Double click the certificate chain for root and intermediate certificates. You can see the full chain when clicked on certification path.
  5. Extract the root and intermediate certificates individually by going to the certification path, select the certificate to be extracted (root or intermediate) and click View Certificate
  6. On the View Certificates pop-up, select the Details tab and click Copy to File
  7. On the Certificate Export wizard, click Next and then select Base 64 encoded X.509 (CER) and then click Next. Export the certificate. 
  8. Name the exported certificate as root and intermediate certificates respectively.
Import CA Certificates

Import the CA certificates in an order, first root certificate, followed by intermediate certificate, and then signed certificate.

  1. Login to the Enterprise Manager console and access the Keystores page by opening Weblogic domain > Security > Keystore.
  2. Under system stripe, select the Identity keystore (custIdentity) and click Manage.
  3. Select CSR and click Import Certificate to import root certificate from CA as trusted certificate (alias myRootCA).
  4. Import intermediate certificate from CA as trusted certificate (alias myInterCA).
  5. Import signed certificate as certificate and select alias as custIdentity from the drop down menu. This should be same alias that used to create keypair for generating CSR.
  6. Select the trust keystore (custTrust) keystore and click Manage.
  7. Click Import Certificate to import root certificate from CA as trusted certificate (alias myRootCA).
  8. Import intermediate certificate from CA as trusted certificate (alias myInterCA).
  9. Import signed certificate as trusted certificate (alias mySignedCert).
  10. To set up cacerts, using Putty, login to Oracle SOA Cloud Service VM and open /u01/jdk/jre/lib/security.
  11. Import the root and intermediate certificates into cacerts using the following commands:
    • keytool -import -keystore cacerts -storepass keystorepassword -file rootCA.crt
    • keytool -import -keystore cacerts -storepass keystorepassword -file interCA.crt
  12. Take a backup from cacerts file, for future use (for example in case of JDK upgrade).
    Whenever there is an upgrade in the JDK, the backup copy needs to be copied back after upgrade as cacerts. Since this is a Oracle SOA Cloud Service instance and all the upgrades are handled automatically, this is a critical step and all the upgrades needs to be tracked.
Sync Keystores

Sync keystores to sync information between Domain Home and the Oracle Platform Security Services store in the database.

To sync keystores:
  1. Login to Oracle SOA Cloud Service VM using Putty.
  2. Open /u01/oracle/middleware/oracle_common/common/bin
  3. Run ./wslt.sh and execute below commands to sync custom identity and custom trust keystores:
    connect('username','password','t3s://<publicIP>:<sslport>')
    svc = getOpssService(name='KeyStoreService') 
    svc. listKeyStoreAliases (appStripe="system”, name="custIdentity”, password=” ****”, type="*") 
    syncKeyStores(appStripe='system',keystoreFormat='KSS') 
    svc. listKeyStoreAliases (appStripe="system”, name="myKSSTrust”, password='****’, type="*") 
    syncKeyStores(appStripe='system',keystoreFormat='KSS')
  4. Restart Admin and Managed Servers.
Update WebLogic Keystores with Custom Identity and Trust

Update the WebLogic keystores with custom identity and custom trust.

  1. On the WebLogic Server Console, open Servers > Admin Server > Configurations > Keystores tab.
  2. Change the Keystores to Custom Identity and Custom Trust and Save.
  3. Provide the values for Custom Identity:
    • Custom Identity Keystore: kss://system/custidentity and click enter.
    • Custom Identity KeyStore Type: KSS and click enter.
    • Custom Identity PassPhrase: enter password given while creating custIdentity keystore.
    • Confirm Custom Identity PassPhrase: enter password given while creating custIdentity keystore.
  4. Provide the values for Custom Trust:
    • Custom Trust Keystore: kss://system/custTrust and click enter.
    • Custom Trust KeyStore Type: KSS and click enter.
    • Custom Trust PassPhrase: enter password given while creating custTrust keystore.
    • Confirm Custom Trust PassPhrase: enter password given while creating custTrust keystore.
  5. Click Save and then activate changes.
  6. Open the SSL tab and provide the following details:
    • Private Key Alias: custIdentity and press enter. This is the alias given while creating keypair in custIdentity keystore.
    • Private Key PassPhrase: Password given while creating key pair under custIdentity keystore.
    • Confirm Private Key PassPhrase: Password given while creating key pair under custIdentity keystore.
  7. In the Advanced section, change Hostname Verification to None. Click Save and activate changes.
    The managed server steps do not require restart. Hence after activating the changes, you can check if the SSL URLs which open on managed server ports show the updated certificates. 
  8. Repeat steps 1 to 7 for Admin Server. Admin Server changes require a restart. 
  9. Stop the Admin, Managed Server, and Node Manager.
    Before restart, make sure the node manager changes are done.
Update Node Manager and boot.properties

Update Node Manager and boot.properties file.

  1. Access the Node Manager by opening /u01/data/domains/<DomainName>/nodemanager.
  2. Edit nodemanager.properties and add the below properties:
    # added for custom identity and custom trust 
    KeyStores=CustomIdentityAndCustomTrust 
    CustomIdentityAlias=custIdentity 
    CustomIdentityKeyStoreFileName=kss://system/custIdentity 
    CustomIdentityKeyStorePassPhrase=********* 
    CustomIdentityKeyStoreType=KSS 
    CustomIdentityPrivateKeyPassPhrase=********* 
    CustomTrustKeyStoreFileName=kss://system/custTrust
  3. Edit startNodeManager.sh file under /u01/data/domains/<YourDomain>/bin/ to add the below properties during startup in JAVA_OPTIONS:
    JAVA_OPTIONS="${JAVA_OPTIONS} 
    -Dweblogic.nodemanager.sslHostNameVerificationEnabled=false -Djava.security.egd=file:/dev/./urandom"

The JAVA_OPTIONS for a Release 12.2.1.2 environment is shown below:

JAVA_OPTIONS="${JAVA_OPTIONS} 
-Doracle.security.jps.config=/u01/data/domains/TPLSOADE_domain/config/fmwconfig/jps-config-jse.xml 
-Dcommon.components.home=/u01/app/oracle/middleware/oracle_common -Dopss.version=12.2.1.2 
-Dweblogic.nodemanager.sslHostNameVerificationEnabled=false -Djava.security.egd=file:/dev/./urandom"

  1. Next, update the boot.properties file by logging in to the Oracle SOA Cloud Service VM through Putty and accessing /u01/data/domains/<YourDomain>/servers/<YourManagedServer>/security.
  2. Take a backup of boot.properties.
  3. Open boot.properties and comment the line #TrustKeyStore=DemoTrust (if present) and Save.
  4. Update the managedServer boot properties by accessing the nodemanager:/u01/data/domains/<YourDomain>/servers/<YourManagedServer>/data/nodemanager
  5. Take a backup of boot.properties.
  6. Edit boot.properties file, comment the line #TrustKeyStore=DemoTrust
  7. Add below lines at the end of boot.properties in managed server:
    CustomTrustKeyStoreFileName=kss://system/custTrust 
    TrustKeyStore=CustomTrust 
    CustomTrustKeyStorePassPhrase=**** 
    CustomTrustKeyStoreType=KSS
  8. Save boot.properties.
  9. To make changes in the SetDomainEnv.sh, remove the following property: Djavax.net.ssl.trustStore=%WL_HOME%\server\lib\DemoTrust.jks
  10. To update the Frontend Host Port, update the host and port in WLS console to reflect the domain name and ports by:
    1. In WLS Console, navigate to the path: Environments > Clusters > Cluster Name > HTTP Tab
    2. Update the Frontend Host as the domain name.
    3. Update the Frontend HTTP Port, default is port 80
    4. Update the Frontend HTTPS Port, default is port 443
  11. Start Node Manager, Admin Server, and Managed Server in that order.
Verify the Environment

When you restart the environment, the admin server and managed server user interface shows the certificates as trusted:

Deploy a helloWorld composite and verify that the client endpoint URL can be opened on https host and port.

The valid certificate chain is present on the client endpoint URL: To invoke the client end point from any other composite, import all the certificates (root, intermediate, and signed) present in the WSDL into the truststore of the server from where the parent composite is deployed.
Two-Way SSL Authentication

Two-way SSL authentication creates a truststore and a keystore on both the client and the server. It is not mandatory to set the two-way authentication.

  1. Login to WebLogic server Console.
  2. On the Managed Server, select the SSL tab and click Advanced.
  3. Select Lock and Edit.
  4. Update field Two Way Client Cert Behavior, select Client Certs Requested and Enforced from the drop-down list.
  5. Click Save and activate the changes.
    This change in the property does not require a WebLogic server restart.