OracleAppsDBAKK1: Enabling TLS in Oracle E-Business Suite Release 12.2 (Doc ID 1367293.1)

This document describes how to encrypt all connections for Oracle E-Business Suite Release 12.2 using Transport Layer Security (TLS).

Note: If you are using SSL or TLS 1.0 and need to review your current configuration or renew your certificate, you can use the instructions found in this document or see My Oracle Support Knowledge Document 2143101.1, Enabling SSL or TLS in Oracle E-Business Suite Release 12.2.

For Oracle E-Business Suite Release 12.1, see either Document 2143099.1, Enabling SSL or TLS in Oracle E-Business Suite Release 12, or Document 376700.1, Enabling TLS in Oracle E-Business Suite Release 12.1, for instructions.

The most current version of this document can be obtained in My Oracle Support Knowledge Document 1367293.1.

In This Document

This document is divided into the following sections:

There is a change log at the end of this document.

Section 1: Introduction

This document describes how to increase communication security by encrypting all Oracle E-Business Suite Release 12.2 network connections using Transport Layer Security (TLS). TLS is the successor to SSL and is a protocol that ensures privacy between communicating applications.

Section 2: How to Use This Document

Note: Before you begin, it is important to understand your current configuration and what you're trying to accomplish. This will help determine the relevant instructions in this document.

Begin by reading Section 3: Terminology and Concepts and Section 4: Oracle E-Business Suite Connections to understand the terminology and concepts used in this document.

Section 5: Enable TLS 1.2 with Backward Compatibility has been broken up into requirements that are needed for inbound, loopback, and outbound connections. Some of the outbound connection requirements in 5.3 Configure Loopback and Outbound Connections may depend on the specific configuration of the server that Oracle E-Business Suite is communicating with.

Section 6: Optional Configurations covers some alternatives that can be implemented to further restrict the protocols used by Oracle E-Business Suite. These include areas such as turning off all protocols except TLS 1.2 or ensuring that Oracle E-Business Suite has no HTTP ports open.

Section 7: Configure Optional Integrations covers the specific configurations that will be required to encrypt communications between Oracle E-Business Suite and some of the optional integrations.

Section 8: Renew Expired Certificates covers the case where you have an existing SSL/TLS instance and only need to renew your certificate. The certificate request remains unchanged, and depending on the Certifying Authority that issued the certificate, will only require the original certificate request to renew the certificate. This section outlines the steps for this process.

Section 9: Alternate TLS Termination Point covers the configuration of Oracle E-Business Suite with an alternate TLS termination point, such as a reverse proxy or load balancer. This section also covers the configuration of end-to-end TLS, where both Oracle E-Business Suite has been configured for TLS, in addition to making use of an alternate TLS termination point.

Section 10: Reuse Certificates covers the case where you have upgraded from Oracle E-Business Suite 11i or 12.0/12.1 and you wish to make use of an existing certificate. The requirements for this are that there is no change in the host name, and that the existing certificate is already SHA-2.

Section 3: Terminology and Concepts

Transport Layer Security (TLS)
Transport Layer Security, or TLS, is the successor of SSL. TLS, like SSL, is a protocol that encrypts traffic between a client and a server. TLS creates an encrypted connection between two machines allowing for private information to be transmitted without the problems of eavesdropping, data tampering, or message forgery. There is no distinction between TLS certificates and SSL certificates issued by certifying authorities.
Secure Sockets Layer (SSL)
SSL is a technology that defines the essential functions of mutual authentication, data encryption, and data integrity for secure transactions. Exchange of data between the client and server in such secure transactions is said to use the Secure Sockets Layer (SSL). This has been deprecated in favor of TLS.
HTTP and HTTPS
HTTP is the primary communication protocol for the World Wide Web. HTTPS is a combination of HTTP and TLS.
Public Key Infrastructure
The term public key infrastructure (PKI) is used to describe the processes, technologies and practices that are required to provide a secure infrastructure. A PKI should provide the following: authentication, non-repudiation, confidentiality, integrity, access control.
Certificate Authority (CA)
A certificate (or certification) authority is a trusted third party responsible for issuing, revoking, and renewing digital certificates. All digital certificates are signed with the certificate authority's private key to ensure authenticity. The certificate authority's public key is widely distributed.
Certificate Signing Request (CSR)
A certificate signing request (CSR) is a digital file which contains your public key and your name. You send the CSR to a certificate authority (CA) to be converted into a real certificate.
Digital Certificate (Public Key)
A digital certificate is an electronic document that binds an identity to a pair of electronic keys that can be used to encrypt and sign digital information. Certificates are issued by a trusted third party, called a certificate authority (CA). The document is usually in a standard X509 format and contains three elements:
1. Entity attributes (information about your organization)
2. Public key (which is bound to the private key)
3. Digital signature by the trusted CA's private key
Types of Digital Certificates
To reduce the number of certificates required for an environment, the following options are available:
- Subject Alternative Name (SAN) Certificate
  The use of the Subject Alternative Name field allows you to specify multiple host names to be protected by a single public key certificate. Use of SAN will also allow for using a single certificate for multiple domains.
- Wild Card Certificate
  A public key certificate which can be used with multiple subdomains of a domain.
Private (Server) Key
The private key file is a digital file that you generate as part of a key pair (private key and public key) and use to encrypt/decrypt messages. The certificate request (CSR) that you send to your certificate authority (CA) is derived from this private key. Therefore, the resulting digital certificate (containing your public key) which is issued by your CA is bound to this private key.
In-House and Self-Signed Certificates
These type of certificates are not publicly available and are used either for internal security reasons, testing purposes, or cost savings. The up side is that customers have full control over these type of certificates, but the down side is that they require additional steps that are not needed in the case of general production certificates. Certificates of this type are still comprised of a root certificate, an intermediate certificate, and the primary server certificate. Server and client side truststores would need to be updated with the full certificate chain in this case. If any component of the certificate chain is not found, errors may be encountered. Be sure you understand the limitations of these certificates when using them in any environment.

TLS Termination Point
A TLS termination point is the end-point server for the encrypted connection that has been initiated by a client (for example, a browser).

In the case of Oracle E-Business Suite, the Oracle HTTP Server can act as a TLS termination point. An alternate TLS termination point, such as a reverse proxy or load balancer, can be configured in front of the Oracle HTTP Server.

Section 4: Oracle E-Business Suite Connections

4.1 Types of Connections
4.2 TLS Versions Certified with Oracle E-Business Suite Connections
4.3 Additional Requirements for Java Web Start (JWS) Users

4.1 Types of Connections

Oracle E-Business Suite connections fall into the following three categories:

We recommend that you configure TLS encryption for all connections in an Oracle E-Business Suite environment.

4.1.1 Inbound Connections

Inbound connections are from a client to the Oracle HTTP Server (OHS) delivered with the Oracle E-Business Suite applications technology stack. With inbound connections, the SHA-2 signed PKI certificate is requested from a CA by your company for your Oracle E-Business Suite OHS. Examples include, but are not limited to, the following:

User accesses Oracle E-Business Suite applications pages through the network using a browser
User accesses Oracle E-Business Suite application through Oracle Forms when using Forms Servlet mode
An XML Gateway message originating from a customer is sent to Oracle E-Business Suite
A mobile phone communications with the Oracle E-Business Suite through a REST service

The following process describes how TLS works with inbound connections to OHS:

The client sends the server its best protocol and a list of cipher suites that it can use.
The server suggests a protocol and a cipher suite from the list.
The server presents its certificate and certificate chain (except the root CA certificate) to the client. This certificate contains the server's identifying information.
The server may also optionally ask for a client certificate from the client (which is validated in a similar manner by the server).
The client checks its trust store (root CA certificates) and validates the chain of trust with the given certificate and certificate chain. If it validates, the server is authenticated as a trusted server.
The client and server perform a key exchange to generate a session key which is used to encrypt subsequent data.

4.1.2 Loopback Connections

Loopback connections are from Oracle E-Business Suite back to the Oracle HTTP Server (OHS) delivered with the Oracle E-Business Suite applications technology stack. Examples include, but are not limited to, the following:

Workflow notification emails from the concurrent manager tier
Payments call back from the database tier
Oracle Process Manager and Notification (OPMN)
Oracle Applications Manager Log Viewer

4.1.3 Outbound Connections

Outbound connections are from Oracle E-Business Suite to external site(s). For outbound connections, the SHA-2 signed PKI certificate is requested from a CA by a site you are connecting to from Oracle E-Business Suite. For this case, Oracle E-Business Suite is acting as an HTTPS client. You must trust the root CA of the remote server's certificate chain in your truststore. Examples include, but are not limited to, the following:

Punchout in Oracle iProcurement
XML Gateway connection to a partner applications
Payments credit card processing
Dunn & Bradstreet (HZ)
International Trade Management (ITM) for screening orders and deliveries
CIS Tax Module

4.2 TLS Versions Certified with Oracle E-Business Suite Connections

Oracle E-Business Suite inbound, outbound, and loopback connections are currently certified with TLS 1.2, 1.1, and 1.0. The default Oracle E-Business Suite configuration provided in Section 5: Enable TLS 1.2 with Backward Compatibility allows for the handshake between the client and server to negotiate and use the highest version of TLS (1.2, 1.1, or 1.0) supported end-to-end by both parties. This configuration is referred to as "TLS 1.2 with backward compatibility."

Example 1: If the outbound connection used by Oracle iProcurement is by default configured for TLS 1.2, 1.1 and 1.0 and if a call is made from Oracle E-Business Suite iProcurement to an external site that supports TLS 1.2 and a common cipher suite is found, then TLS 1.2 will be used end-to-end. If a call is made from Oracle E-Business Suite iProcurement to an external site that supports TLS 1.1 and a common cipher suite is found, then the handshake negotiation will resolve to use TLS 1.1.

Example 2: If the Oracle E-Business Suite Oracle HTTP Server (OHS) for inbound connections is by default configured for TLS 1.2, 1.1 and 1.0. If a client using a browser that supports TLS 1.2 attempts to connect to the OHS, then TLS 1.2 will be used. If a client using a browser that supports only up to TLS 1.1 attempts to connect to the OHS, then the handshake negotiation between the server and client will dictate the use of TLS 1.1.

You may optionally configure Oracle E-Business Suite to use the highest level of TLS certified with Oracle E-Business Suite Release 12.2. See 6.1 Configure TLS 1.2 Only for more details.

The default requirements and configuration provided in Section 5: Enable TLS 1.2 with Backward Compatibility provides the ability to use SHA-2 signed PKI certificates and also addresses recent security vulnerabilities including:

Weak cipher suites (FREAK, LOGJAM, RC4 NOMORE)
POODLE

While RSA is the most commonly used certificate key type and is supported by Oracle E-Business Suite, Oracle Fusion Middleware supports the use of an Elliptic Curve Cryptography (ECC) certificate if the entire chain is ECC and the server cert is signed using ecdsasha256. We currently do not support an ECC certificate with the server cert signed using sha256WithRSAEncryption, and intermediate and root CA using RSA. The procedures in this note apply to customers using either RSA or ECC certificates unless otherwise noted.

4.3 Additional Requirements for Java Web Start (JWS) Users

SSL and TLS users running Java Web Start (JWS) require a chain of trust to the Java certificate store for their server certificate on the desktop. This is in addition to the usual chain of trust to the browser.

If using a recognized certificate authority (CA), there should be no further requirements as the server certificate will already be included be in the Java 'System' store by default.

If using your own in-house CA, you must import the server root certificate into the Java 'Secure Site CA' certificate store through the Java Control Panel. To do so:

Navigate to the Security tab in the Java Control Panel.
Click Manage Certificates.
For Certificate Type, select "Secure Site CA" from the drop-down list.
Click Import.

Without this chain of trust, you will see a Security Warning dialog box stating "The connection to this website is untrusted" when trying to run Java content within Oracle E-Business Suite.

Section 5: Enable TLS 1.2 with Backward Compatibility

This section details the steps necessary to enable TLS 1.2 with backward compatibility. The configuration and patches in this section also address recent vulnerabilities including weak cipher suites, FREAK, POODLE, and DROWN.

5.1 Apply Required Updates and Patches
5.2 Configure Inbound Connections
5.3 Configure Loopback and Outbound Connections
5.4 Enable TLS for WLS AdminServer

5.1 Apply Required Updates and Patches

Install the following prerequisite software updates and components on your Oracle E-Business Suite Release 12.2 instance. These software updates are fully compatible with Oracle E-Business Suite environments regardless of whether or not you proceed with TLS configuration. You may therefore choose to install these software updates at an earlier date, even before performing any of the subsequent steps in this document to complete TLS configuration. You may combine these updates with other regularly-scheduled maintenance in your environment. You can choose to install these software updates during an Oracle E-Business Suite R12.2 Online Patching cycle to your patch file system (recommended) or on your run file system.

For details about Oracle E-Business Suite Release 12.2 online patching, refer to Patching Procedures in the Oracle E-Business Suite Maintenance Guide Release 12.2.

Perform the following steps to apply the necessary updates and patches.

Step 1 - Upgrade to Latest Java Development Kit (JDK) 7

Note: AIX customers must upgrade their application tier JDK to a minimum of JDK 1.7 SR10 FP1.
Follow the instructions in Section 3 of Document 1530033.1, Using the Latest JDK 7.0 Update with Oracle E-Business Suite Release 12.2.
Starting with the January 2017 Java CPU, TLS 1.1 and TLS 1.2 are enabled by default. The specific minimum versions are JDK 1.7.0_131.

Step 2 - Upgrade Oracle Fusion Middleware

The use of TLS 1.2 requires Oracle Fusion Middleware 11.1.1.9. For more information, see Document 1590356.1, Upgrading Oracle Fusion Middleware WebTier of Oracle E-Business Suite Release 12.2 to the latest 11gR1 (11.1.1.x) PatchSet.
On top of Oracle Fusion Middleware 11.1.1.9, it is required that you apply the July 2016 Critical Patch Update (CPU) or later for TLS 1.2 support. we highly recommend you take up the latest CPU. For the latest CPU, see Document 2484000.1, Identifying the Latest Critical Patch Update for Oracle E-Business Suite Release 12.

Step 3 - Apply AD and TXK Patches

We highly recommend that you apply the latest AD and TXK Delta Release Update Packs. Refer to Document 1617461.1, Applying the Latest AD and TXK Release Update Packs to Oracle E-Business Suite Release 12.2, for the latest information on known issues. Within that same note, review Section 4: Apply Additional Critical Patches for any AD/TXK patches that may be applicable.

Step 4 - Apply Product-Specific Patches

Apply the following product-specific patches:
Oracle Workflow
Apply Patch 22806350:R12.OWF.C to address an Oracle Workflow Notification Mailer issue.

Oracle iProcurement
Apply the patch or patches as mentioned in Document 1937220.1, Punchout in Oracle iProcurement and Exchange Fails After Supplier Site Migrates From SSLv3 to TLS Protocol (with SSL Handshake SSLIOClosedOverrideGoodbyeKiss), which corresponds to the appropriate application versions.

Oracle XML Gateway
Apply Patch 22326911:R12.ECX.C.

Oracle iPayment
Apply Patch 22522877:R12.IBY.C.

Note: For Oracle Payments and Paymentech integration there is a new parameter for SSL Enabled in the transmission configuration for the protocol for Paymentech Online Spec Socket. This is available in controlled released Patch 29179872. Refer to Document 2531952.1, Oracle Payments 12.2: After uptake to TLS 1.2 Paymentech Authorizations No Longer Working.

Step 5 - Apply Oracle Fusion Middleware Patch 23630525 and Patch 26045188 Version 11.1.1.9

It is safe to roll back Patch 25072950 in the case of a conflict.
After applying Patch 26045188, remove the NonJ2EEManagement deployment from the WebLogic console and then proceed with redeployment by performing the following steps:
Navigate to the WebLogic Server Admin Console at http://<s_wls_admin_host>.<s_wls_admin_domain>:<s_wls_admin port>/console and derive context variable values using either the run or patch edition context file, dependent on your current patching state.
From the Domain Structure panel, navigate to Deployments.
Locate in the list of deployments NonJ2EEManagement (11.1.1).
Stop the application “NonJ2EEManagement (11.1.1)”.
In the Change Center panel, click Lock & Edit.
Select the check box beside the deployed application NonJ2EEManagement (11.1.1).
Delete the NonJ2EEManagement (11.1.1) application.
Click Activate Changes.
Redeploy the $ORACLE_HOME/opmn/applications/NonJ2EEManagement.ear file delivered by this patch:
$ $ORACLE_HOME/opmn/bin/opmnctl redeploy -adminHost <ADMINSERVER_HOST> -adminPort <ADMINSERVER_PORT>

Step 6 (Optional) - Apply Prerequisite Patches for Implementing TLS for ECC Certification

If you are using Oracle Database 11.2.0.4, you must apply the October 2018 PSU or later to support ECC certificates.
If you are using Oracle Database 12c, skip this step.

5.2 Configure Inbound Connections

The steps below are for the minimum requirements for inbound connections to the Oracle E-Business Suite application tier Oracle HTTP Server (OHS) to enable TLS and for the use of SHA-2 signed PKI certificates.

Step 1 - Set Your Environment

Note: The steps detailed in this section must be executed on the run file system in order to ensure that during the next online patching the TLS setup is then propagated to the patch file system. There should not be an active patching cycle at this point. In order to check whether an online patching cycle is already active or not, you can use the following command:
UNIX:
$ adop -status
Windows:
C:\> adop.cmd -status
Log on to the Oracle E-Business Suite Release 12.2 application tier as the OS user who owns the installation files.
The file system with the Applications context file variable s_file_edition_type set to 'run' denotes the run file system. Source your application tier environment file (<sid_machine>.env), located in the APPL_TOP directory on the run file system. Do not source the APPS<sid_machine>.env file, otherwise the 10.1.2 environment variables will be picked up and Oracle Wallet Manager 11g will fail to start. After sourcing the environment file, the $FILE_EDITION environment variable should be 'run'.
Set the PATH environment variable to include the Fusion Middleware location.
For example:
$ export PATH=$FMW_HOME/webtier/bin:$FMW_HOME/oracle_common/bin:$PATH
Set the DISPLAY environment variable.
For example:
$ export DISPLAY=<hostname or ip address>:0.0
Note: If you have previously configured Oracle E-Business Suite with SSL or TLS 1.0 and have a valid server certificate, skip steps 2 through 6 and continue with step 7.

Step 2 - Create a Wallet

Note: When working with wallets and certificates, you must use the Oracle Fusion Middleware 11g executables. These instructions involve the use of the Oracle Wallet Manager graphical user interface. Oracle Wallet Manager command line interface orapki or Fusion Middleware Control can also be used to manage various aspects of keystores. These tools are detailed in the Fusion Middleware Documentation Library.
The s_web_ssl_directory location is still used by some Oracle E-Business Suite Release 12.2 components (for example, XML Gateway Transportation Agent OXTA) and during the Oracle Fusion Middleware cloning process. Refer to the Applications context file for the exact location of the s_web_ssl_directory variable. The process outlined in this section creates the wallet in this location and it is then copied to the new web tier location.
Navigate to the <s_web_ssl_directory>/Apache directory. If it does not exist, create it.
Move any existing wallet files to a backup directory in case you wish to use them again in the future.
Open Oracle Wallet Manager as a background process:
$ owm &
For Windows, Oracle Wallet Manager can be launched from the run file system as follows:
Navigate to Start, click Run.
Input the following into the text field: <FMW_Home>\webtier\bin\launch.exe "<FMW_Home>\webtier\bin" owm.cl
Click OK.

On the Oracle Wallet Manager menu, navigate to Wallet, then select New.
When prompted "Your default wallet directory doesn't exist. Do you wish to create it now?”, answer No.
The new wallet screen will now prompt you to enter a password for your wallet. Be sure to make the password something you will remember. You will need to use the password whenever you open the wallet with Oracle Wallet Manager or perform operations on the wallet using the command line interface. With auto login enabled processes submitted by the OS user who created the wallet, there is no need to supply the password to access the wallet.
When prompted “A new empty wallet has been created. Do you wish to create a certificate request at this time?”, answer Yes.
If you are using a self-signed certificate (for testing purpose) or a CA-signed Elliptic Curve Cryptography (ECC) certificate, follow the procedure below:
Navigate to the <s_web_ssl_directory>/Apache directory.
Instead of using Oracle Wallet Manager, perform the following to create an empty wallet:
$ . $FMW_HOME/user_projects/domains/<EBS_domain>/bin/setDomainEnv.sh $ cd <s_web_ssl_directory>/Apache $ $FMW_HOME/oracle_common/bin/orapki wallet create -wallet ./ -auto_login_only

Step 3 - Create a Certificate Request

Note: The values for the elements in your certificate signing request's Distinguished Name may be dictated by your local policies or the policies of the commercial Certificate Authority you will use to sign your certificate. Check local and CA policies to determine acceptable values before generating the CSR.

After clicking "Yes" in the previous step, the "Create Certificate Request Screen" will appear. Enter the appropriate values. For example:
Common Name: Name of your server, including the domain
Organizational Unit: (optional) Unit within your organization
Organization: Name of your organization
Locality/City: Locality or city
State/Province: The full name of your State or Province (do not abbreviate)
Select your Country from the drop-down list. For the Key Size, select 2048 as a minimum. Click OK.
From the menu, click Wallet and then click Save.
On the Select Directory screen, change the directory to your fully qualified wallet directory and click OK.
From the menu, click Wallet and select the Auto Login check box.
Exit Oracle Wallet Manager.
The wallet directory will contain the files cwallet.sso and ewallet.p12.
Note: For Oracle Fusion Middleware 11.1.1.9 you will also see two additional files, cwallet.sso.lck and ewallet.p12.lck. These are lock files generated by Oracle Wallet Manager.
To create a self-signed certificate, run the following:
$ $FMW_HOME/oracle_common/bin/orapki wallet add -wallet ./ -dn "CN=<hostname.domainname>" -keysize 2048 -self_signed -validity 365 -auto_login_only
To create a self-signed ECC certificate, run the following:
$ $FMW_HOME/oracle_common/bin/orapki wallet add -wallet ./ -dn "CN=<hostname.domainname>" -sign_alg ecdsasha256 -asym_alg ECC -eccurve secp256r1 -self_signed -validity 365 -auto_login_only -jsafe

If using a CA-signed ECC certificate, run the following:

$ DN="CN=<hostname.domainname>,O=<Organization name>,OU=<Organization unit>,L=<Organization location>,ST=<Organization state location>,C=<country>"
$ $FMW_HOME/oracle_common/bin/orapki wallet add -wallet ./ -dn "$DN" -sign_alg ecdsasha256 -asym_alg ECC -eccurve secp256r1 -auto_login_only -jsafe
If you use wildcard certificate to protect multiple servers, specify the server name as an asterisk (*) plus the domain in Common Name. For example: *.example.com .
If you use SAN (Subject Alternative Name) certificate to protect multiple servers, specify/add the SAN information in the order form when submitting the CSR to CA and then the issued certificate will contain the SAN elements, which is supported by most CAs nowadays. In case this is NOT supported by the CA and you need to add SAN information in the CSR before submitting, perform the following:
Use OpenSSL to take the existing wallet and save it as a new PEM format file:
% openssl pkcs12 -in ewallet.p12 -nodes -out nonoracle_wallet.pem
Create an openssl config file new.cnf with following contents:
[req] distinguished_name = dn req_extensions = ext prompt = no [dn] CN = hostname.example.com O = Example Inc OU = Key Team L = San Diego ST = California C = US [ext] subjectAltName = DNS:hostname1.example.com,DNS:hostname2.example.com,DNS:hostname3.example.com
Note:
Set Common Name (CN) to one of your hostnames, such as: CN = hostname.example.com
Include all the host names in SAN (subjectAltName), such as: subjectAltName = DNS:hostname1.example.com,DNS:hostname2.example.com,DNS:hostname3.example.com.
Use OpenSSL to generate the request specifying SHA-2:
% openssl req -new -config new.cnf -key nonoracle_wallet.pem -sha256 -out server.csr
Submit server.csr to CA.

Step 4 - Submit the Certificate Request to a Certificate Authority

Note: Signature Algorithm Changes
Industry standards for encryption algorithms are constantly under review. Certificates issued with a SHA-1 based signature hash algorithm as an industry standard are being phased out. Many certificate authorities now mandate SHA-2 as the minimum signature algorithm for issuing certificates and no longer issue SHA-1 certificates. The time frame for moving to SHA-2 varies depending upon the certificate authority that is used. The requirement for SHA-2 also impacts intermediate certificates which must also be SHA-2 in order to chain back to the end-entity SHA-2 certificate issued. Root certificates are not impacted.

Reference the following My Oracle Support Knowledge Documents for more information:
Document 1448161.1, How To Produce CSR With A SHA-1 Or Better Signature Algorithm
Document 1275428.1, Support Status for SHA2 in Oracle WebLogic Server, Fusion Middleware 11g/12c and Oracle Application Server 10g
Document 1939223.1, How to Generate SHA2 Certificate Signing Requests WITHOUT Oracle Wallet Manager for FMW 11g Wallets
Depending on your certificate provider, MD5-based certificate requests (CSR) generated by Oracle Wallet Manager (OWM) may not be accepted.
For example, Symantec will now only accept SHA-1 2048-bit based CSRs or higher. Due to a current limitation in both OWM and orapki, they are incapable of generating anything other than MD5-based CSRs. OWM can accept SHA-2 or previously trusted certificates and server certificates, it just cannot generate them.
In these cases, the workaround is to make use of OpenSSL to generate the CSR. An example of this process is provided below.
Use OpenSSL to take the existing wallet and save it as a new PEM format file:
$ openssl pkcs12 -in ewallet.p12 -nodes -out nonoracle_wallet.pem
Use OpenSSL to generate the request specifying SHA-2:
$ openssl req -new -key nonoracle_wallet.pem -sha256 -out server.csr
At this point, OpenSSL will prompt you for the request attributes. Be sure to enter the same data you entered when creating the CSR in OWM in Step 3 - Create a Certificate Request. Do not specify a 'challenge password' as this has been deemed to be insecure by most certifying authorities.
The server.csr should now be submitted to your certificate authority to request a server certificate.

Upon receiving your newly issued certificate, you can import this into your wallet using OWM continuing with the next step below, Step 5 - Import Server Certificate to the Wallet.
Note: Skip this step if you are using a self-signed ECC certificate.
For customers planning to get an ECC certificate from a certificate authority, perform the following to generate a CSR file:
$ $FMW_HOME/oracle_common/bin/orapki wallet export -wallet ./ -dn "$DN" -request server.csr -jsafe
This server.csr should now be submitted to your certificate authority to request a server certificate.

Step 5 - Import the Server Certificate to the Wallet

After you receive your server certificate from your certificate authority, you will need to import it into your wallet. Copy the certificate to a file server.crt (example file name) in the wallet directory on your server by one of the following methods:
Use scp or sftp (in binary mode) to copy the certificate.
Copy and paste the certificate contents into server.crt (example file name).
Steps to import server.crt into your wallet:
Note: If all trusted certificates that make up the chain of server certificate are not present in the wallet, adding the certificate will fail. When the wallet was created, only the certificates for the most common CAs were included automatically. Contact your certificate authority if you need to add their certificate, and save the provided file (for example, as ca.crt) in the wallet directory. If your certificate authority provided an intermediate certificate (to complete the chain) then save the provided file (for example, as intca.crt, this will need to be imported into Oracle Wallet Manager prior to importing the server certificate (server.crt if you used the example name).
Open Oracle Wallet Manager as a background process:
$ owm &
For Windows, Oracle Wallet Manager can be launched from the run file system as follows:
Navigate to Start, then click Run.
Input the following into the text field: <FMW_Home>\webtier\bin\launch.exe "<FMW_Home>\webtier\bin" owm.cl
Click OK.

From the menu, click Wallet, then Open.

Answer Yes when prompted:
Your default wallet directory does not exist.
Do you want to continue?

On the Select Directory screen, change the directory to your fully qualified wallet directory <s_web_ssl_directory>/Apache and click OK.

Enter your wallet password and click OK.

In the Oracle Wallet Manager menu, navigate to Operations - Import Trusted Certificate.

These are comprised of the root CA and intermediate certificates.

Click OK.

Select the ca.crt (root certificate provided by your certificate authority).

Do the same with the intca.crt (intermediate certificate provide by your certificate authority).

In the Oracle Wallet Manager menu, navigate to Operations - Import User Certificate.

Server certificates are a type of user certificate. Since the certificate authority issued a certificate for the server, placing its distinguished name (DN) in the Subject field, the server is the certificate owner, and thus the "user" for this user certificate.

Click OK.

Double-click server.crt to import it.

Save the wallet:
In the Oracle Wallet Manager menu, click Wallet.
Verify the Auto Login check box is selected.
Click Save.
If you need to import the CA certificate, you'll also need to add the contents of root certificate (ca.crt) file to the b64InternetCertificate.txt file located in the 10.1.2 ORACLE_HOME/sysman/config directory.
$ cat ca.crt >> <10.1.2 ORACLE_HOME>/sysman/config/b64InternetCertificate.txt
If using a self-signed ECC certificate, skip this step.
For customers obtaining an ECC certificate from a certificate authority, perform the following:
After you receive your server certificate from your certificate authority, you will need to import it into your wallet. Copy the certificate to a file server.crt (example file name) in the wallet directory on your server by one of the following methods:
Use scp or sftp (in binary mode) to copy the certificate.
Copy and paste the certificate contents into server.crt (example file name).
Import the root certificate into the wallet:
$ $FMW_HOME/oracle_common/bin/orapki wallet add -wallet ./ -trusted_cert -cert rootca.crt -auto_login_only -jsafe

If your certificate authority provides an intermediate certificate, then perform the following to import that certificate into the wallet:
$ $FMW_HOME/oracle_common/bin/orapki wallet add -wallet ./ -trusted_cert -cert intca.crt -auto_login_only –jsafe
Import the server certificate into the wallet:
$ $FMW_HOME/oracle_common/bin/orapki wallet add -wallet ./ -user_cert -cert server.crt -auto_login_only -jsafe

Step 6 - Modify the Oracle HTTP Server Wallet

The default location for the Oracle HTTP Server configuration is in a location specific to the Oracle Fusion Middleware web tier. The <s_web_ssl_directory>/Apache is still used by some Oracle E-Business Suite Release 12.2 components, but is not used by the Oracle HTTP Server. Use the following instructions to copy the <s_web_ssl_directory>/Apache wallet to <s_ohs_instance_loc>/config/OHS/<s_ohs_component>/keystores/default directory location:
Navigate to the <s_ohs_instance_loc>/config/OHS/<s_ohs_component>/keystores/default directory location. Refer to the Application context file for the exact location of the s_ohs_instance_loc variable (details the ohs instance location) and the s_ohs_component variables (name of a specific ohs component for example OHS).
Move the existing wallet files to a backup directory in case you wish to use them again in the future.
Copy the cwallet.sso file from <s_web_ssl_directory>/Apache into the current directory.

Step 7 - Modify the OPMN Wallet and Configure the Cipher Suites

Modify the OPMN Wallet
The default location for the OPMN wallet is in the <s_ohs_instance_loc>/config/OPMN/opmn/wallet directory. Refer to the Application Context file for the exact location of the <s_ohs_instance_loc> variable (gives details of the OHS instance location).
Now that the web tier wallet has been created, you will need to use these same certificates for OPMN. Use the following steps to backup and copy the wallets:
Navigate to the <s_ohs_instance_loc>/config/OPMN/opmn/wallet directory.
Move the existing wallet files to a backup directory in case you wish to use them again in the future.
Copy the cwallet.sso files from the <s_ohs_instance_loc>/config/OHS/<s_ohs_component>/keystores/default directory to the current directory.
Configure the OPMN Cipher Suites
You must perform this configuration to enforce strong cipher suites on the OPMN remote port.
Ensure all processes are down.
Open the opmn.xml file located under your web tier instance directory $FMW_HOME/webtier/instances/<s_ohs_instance>/config/OPMN/opmn.
Towards the top of the file, look for the SSL options within the <notification-server> section.
Change:
<ssl enabled="true"      wallet-file="<path to the wallet file>"/>
to
<ssl enabled="true"     wallet-file="<Path to the Wallet file>" ssl-versions="TLSv1.0,TLSv1.1,TLSv1.2"     ssl-ciphers="<Pick two ciphers from the list of valid ciphers below,separated by a comma>"/>
The following list specifies the valid cipher suites that can be used:
SSL_RSA_WITH_AES_256_CBC_SHA
SSL_RSA_WITH_AES_128_CBC_SHA
For example:
<ssl enabled="true"     wallet-file="/EBS_web_EBSDB_OHS1/config/OPMN/opmn/wallet" ssl-versions="TLSv1.0,TLSv1.1,TLSv1.2" ssl-ciphers="SSL_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_AES_128_CBC_SHA"/>

If using an ECC certificate, no need to specify any ciphers. You must remove the ssl-ciphers line from opmn.xml.
Edit the admin.conf file located under the $FMW_HOME/webtier/instances/<s_ohs_instance>/config/OHS/<s_ohs_component> directory.
Change:
SSLCipherSuite SSL_RSA_WITH_RC4_128_SHA SSLProtocol nzos_Version_1_0 nzos_Version_3_0
to
SSLCipherSuite SSL_RSA_WITH_AES_256_CBC_SHA:SSL_RSA_WITH_AES_128_CBC_SHA SSLProtocol nzos_Version_1_0 nzos_Version_1_1 nzos_Version_1_2
If using an ECC certificate, no need to specify any ciphers. You must comment out the SSLCipherSuite line or delete it because the RSA ciphersuites we used for the RSA certificate will not work with the ECC certificate.

Note: If you are configuring Oracle E-Business Suite Release 12.2 to use TLS 1.2 only, the value used for admin.conf will differ. Refer to "Configure Inbound Connections" in 6.1 Configure TLS 1.2 Only for details.

Step 8 - Modify the Oracle Fusion Middleware Wallets

The Fusion Middleware Control Console uses the functionality of OPMN to manage your Oracle Fusion Middleware Enterprise. Using a web browser, the Fusion Middleware Control Console provides a graphical interface that enables management of all system components in your network and enterprise. Changes made in the previous steps to the OPMN wallet also need to be made to the wallet used by Fusion Middleware Control MBeans, which rely on successful TLS communication to manage the OPMN based components.
Use the following steps to backup and copy the wallets. If the Fusion Middleware Control wallets contain additional certificates that are not stored in the web tier OPMN wallet, you may want to export them and then re-import them after the following steps have been completed:
Move the existing wallet files to a backup directory in case you wish to use them again in the future. Refer to the Application context file for the variables for your instance:
$EBS_DOMAIN_HOME/opmn/<s_ohs_instance>/<s_ohs_component>/wallet
$EBS_DOMAIN_HOME/opmn/<s_ohs_instance>/wallet
$FMW_HOME/webtier/instances/<s_ohs_instance>/config/OHS/<s_ohs_component>/proxy-wallet

Copy the cwallet.sso file from the <s_ohs_instance_loc>/config/OPMN/opmn/wallet directory to all three locations listed in the previous step.
Note: In the case of a multinode configuration that is also using a shared or non-shared file system, updates to the first two directories...
$EBS_DOMAIN_HOME/opmn/<s_ohs_instance>/<s_ohs_component>/wallet
$EBS_DOMAIN_HOME/opmn/<s_ohs_instance>/wallet
...are done on the primary node, and updates to the third directory...
$FMW_HOME/webtier/instances/<s_ohs_instance>/config/OHS/<s_ohs_component>/proxy-wallet
...are done on the respective applications tier node where OHS is being configured for TLS. The reason being is that the first two directories will only exist on the primary node, and the third directory will only exist on each applications tier node where OHS is enabled.

Step 9 - Update the Context File and Config Files

Change the TLS-related parameters as shown in OHS as the TLS Termination Point or reference Section 9: Alternate TLS Termination Point depending upon your configuration of the TLS termination point.
OHS as the TLS Termination Point
Use Oracle Fusion Middleware Control to make some additional configuration file changes:
Log in to Oracle Fusion Middleware Control Console (for example, http://<hostname>.<domain>:<AdminServer Port>/em).
Select web tier target under the EBS domain.
Navigate to Administration, then Advanced Configuration.
Select ssl.conf file for edit.
Update the Listen <port> and the VirtualHost _default_:<port> directives to SSL port, for example Listen 4443.
Update the SSLProtocol and SSLCipherSuite entry to match the following:
SSLProtocol TLSv1 TLSv1.1 TLSv1.2 SSLCipherSuite HIGH:MEDIUM:!aNULL:!RC4:!3DES:!SEED:!IDEA:!CAMELLIA:+HIGH:+MEDIUM
If using an ECC certificate, no need to specify any ciphers. You can comment out the SSLCipherSuite line. Due to a known issue as described in bug 26493558, you will need to edit the ssl.conf file manually from the command line.

Note: If you are configuring Oracle E-Business Suite Release 12.2 to use TLS 1.2 only, the value used for SSLProtocol will differ. Refer to "Configure Inbound Connections" in 6.1 Configure TLS 1.2 Only for details.

Click Apply.
The following command should be run (on all application tier nodes) to propagate the changes made through the Oracle Fusion Middleware Control Console to the context file variables:
$ perl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE Enter the APPS user password: Enter the WebLogic AdminServer password:
For Windows:
C:\> perl %AD_TOP%\bin\adSyncContext.pl contextfile=%CONTEXT_FILE%
Review the adSyncContext.log for the changes that have been picked up and made to the context file.
Note: When setting up TLS for the first time, the default protocol will be set to 'http' and only the port related context variables will be updated by running adSyncContext.pl. Additional URL-based context variables <s_login_page> and <s_external_url> will need to be updated using Oracle Applications Manager (OAM). On an instance where the protocol is already set to 'https', then these context variables will be updated as long as the <port> matches the existing value defined for s_active_webport. Otherwise, it is assumed that the login-related URLs have been customized and should not be automatically changed.
Use the Oracle E-Business Suite 12.2 - OAM Context Editor to change the TLS-related variables shown in this table:
TLS-Related Variables in the Context File
Variable Non-TLS Value TLS Value
s_url_protocol http https
s_local_url_protocol http https
s_webentryurlprotocol http https
s_active_webport Same as s_webport Same as s_webssl_port
s_webssl_port Not applicable Default is 4443
s_https_listen_parameter Not applicable Same as s_webssl_port
s_login_page URL constructed with HTTP protocol and s_webport URL constructed with HTTPS protocol and s_webssl_port
s_external_url URL constructed with HTTP protocol and s_webport URL constructed with HTTPS protocol and s_webssl_port
The value of the s_webport is based on the default port prior to any TLS configuration and remains unchanged when switching to TLS.

Variable	Non-TLS Value	TLS Value
`s_url_protocol`	http	https
`s_local_url_protocol`	http	https
`s_webentryurlprotocol`	http	https
`s_active_webport`	Same as s_webport	Same as s_webssl_port
`s_webssl_port`	Not applicable	Default is 4443
`s_https_listen_parameter`	Not applicable	Same as s_webssl_port
`s_login_page`	URL constructed with HTTP protocol and s_webport	URL constructed with HTTPS protocol and s_webssl_port
`s_external_url`	URL constructed with HTTP protocol and s_webport	URL constructed with HTTPS protocol and s_webssl_port

Step 10 - Run AutoConfig

Run AutoConfig using the adautocfg.sh script in the application tier $ADMIN_SCRIPTS_HOME directory.

Step 11 - Restart the Application Tier Services

Use the adstpall.sh/adstrtal.sh script in the $ADMIN_SCRIPTS_HOME directory to stop and restart all services.
Note: The basic configuration can now be tested on the current run file system. Please refer to 5.3.2 Database Tier Setup if you wish to test Oracle products that rely on the database tier setup being completed.

Step 12 - Propagate TLS Changes to Patch File Systems

The following steps must be performed in order to synchronize the TLS setup between the two file systems:
Edit $APPL_TOP_NE/ad/custom/adop_sync.drv.
Assuming the rsync command is available on UNIX, the following directives must be copied and pasted between the <Begin Customization> and <End Customization> section after the existing <#Copy Ends>:
Example commands:
#TLS SECTION - START # Required for TLS setup migration from RUN to PATCH file-system. # Please alter the commands in the event that rsync is not available or the platform does not support the example syntax. #10.1.2 b64InternetCertificate.txt rsync -zr %s_current_base%/EBSapps/10.1.2/sysman/config/b64InternetCertificate.txt %s_other_base%/EBSapps/10.1.2/sysman/config/b64InternetCertificate.txt #Oracle HTTP Server Wallet - cwallet.sso rsync -zr %s_current_base%/FMW_Home/webtier/instances/%s_ohs_instance%/config/OHS/%s_ohs_component%/keystores/default/cwallet.sso %s_other_base%/FMW_Home/webtier/instances/%s_ohs_instance%/config/OHS/%s_ohs_component%/keystores/default/cwallet.sso #OPMN Wallet - cwallet.sso rsync -zr %s_current_base%/FMW_Home/webtier/instances/%s_ohs_instance%/config/OPMN/opmn/wallet/cwallet.sso %s_other_base%/FMW_Home/webtier/instances/%s_ohs_instance%/config/OPMN/opmn/wallet/cwallet.sso #Fusion Middleware Control Wallets - cwallet.sso rsync -zr %s_current_base%/FMW_Home/user_projects/domains/%s_wls_domain_name%/opmn/%s_ohs_instance%/%s_ohs_component%/wallet/cwallet.sso %s_other_base%/FMW_Home/user_projects/domains/%s_wls_domain_name%/opmn/%s_ohs_instance%/%s_ohs_component%/wallet/cwallet.sso rsync -zr %s_current_base%/FMW_Home/user_projects/domains/%s_wls_domain_name%/opmn/%s_ohs_instance%/wallet/cwallet.sso %s_other_base%/FMW_Home/user_projects/domains/%s_wls_domain_name%/opmn/%s_ohs_instance%/wallet/cwallet.sso rsync -zr %s_current_base%/FMW_Home/webtier/instances/%s_ohs_instance%/config/OHS/%s_ohs_component%/proxy-wallet/cwallet.sso %s_other_base%/FMW_Home/webtier/instances/%s_ohs_instance%/config/OHS/%s_ohs_component%/proxy-wallet/cwallet.sso
For Windows:
#TLS SECTION - START # Required for TLS setup migration from RUN to PATCH file-system. # Please alter the commands in the event that rsync is not available or the platform does not support the example syntax. #10.1.2 b64InternetCertificate.txt xcopy /ieqy %s_current_base%\EBSapps\10.1.2\sysman\config\b64InternetCertificate.txt %s_other_base%\EBSapps\10.1.2\sysman\config\b64InternetCertificate.txt #Oracle HTTP Server Wallet - cwallet.sso xcopy /ieqy %s_current_base%\FMW_Home\webtier\instances\%s_ohs_instance%\config\OHS\%s_ohs_component%\keystores\default\cwallet.sso %s_other_base%\FMW_Home\webtier\instances\%s_ohs_instance%\config\OHS\%s_ohs_component%\keystores\default\cwallet.sso #OPMN Wallet - cwallet.sso xcopy /ieqy %s_current_base%\FMW_Home\webtier\instances\%s_ohs_instance%\config\OPMN\opmn\wallet\cwallet.sso %s_other_base%\FMW_Home\webtier\instances\%s_ohs_instance%\config\OPMN\opmn\wallet\cwallet.sso #Fusion Middleware Control Wallets - cwallet.sso xcopy /ieqy %s_current_base%\FMW_Home\user_projects\domains\%s_wls_domain_name%\opmn\%s_ohs_instance%\%s_ohs_component%\wallet\cwallet.sso %s_other_base%\FMW_Home\user_projects\domains\%s_wls_domain_name%\opmn\%s_ohs_instance%\%s_ohs_component%\wallet\cwallet.sso xcopy /ieqy %s_current_base%\FMW_Home\user_projects\domains\%s_wls_domain_name%\opmn\%s_ohs_instance%\wallet\cwallet.sso %s_other_base%\FMW_Home\user_projects\domains\%s_wls_domain_name%\opmn\%s_ohs_instance%\wallet\cwallet.sso xcopy /ieqy %s_current_base%\FMW_Home\webtier\instances\%s_ohs_instance%\config\OHS\%s_ohs _component%\proxy-wallet\cwallet.sso %s_other_base%\FMW_Home\webtier\instances\%s_ohs_instance%\config\OHS\%s_ohs_component%\proxy-wallet\cwallet.sso
Refer to the Application context file variable <s_fmw_jdktop> to determine the JDK version currently being used, then add the JDK copy directive, detailed below.
JDK
The use of rsync for JDK insures that the location of the keystore cacerts file is included for the patch file system.
Example command for UNIX:
#JDK keystore rsync -zr --include=jdk* --include=jdk*/jre --include=jdk*/jre/lib --include=jdk*/jre/lib/security --include=cacerts --exclude=* %s_current_base%/EBSapps/comn/util/ %s_other_base%/EBSapps/comn/util/ #TLS SECTION - END
For JDK on Windows:
#JDK keystore for /f %%A in ('dir /b %s_current_base%\EBSapps\comn\util\jdk*') do (xcopy /ieqy %s_current_base%\EBSapps\comn\util\%%A\jre\lib\security\cacerts %s_other_base%\EBSapps\comn\util\%%A\jre\lib\security\cacerts) #TLS SECTION - END
For more information on JDK 7, refer to Document 1530033.1, Using the Latest JDK 7.0 Update with Oracle E-Business Suite Release 12.2.
Note: The changes are propagated to the patch file system during the prepare phase (adop phase=prepare) of online patching and take affect after a successful cutover (adop phase=cutover). The TLS setup can then be verified as the patch file system has now been promoted to be the new run file system.
In the cases involving multiple middle-tier nodes using either a Wild Card or SAN certificate, the following files need to be copied over to each node, and Step 12 repeated for each node.
$ORACLE_HOME/sysman/config/b64InternetCertificate.txt $FMW_Home/webtier/instances/%s_ohs_instance%/config/OHS/%s_ohs_component%/keystores/default/cwallet.sso $FMW_Home/webtier/instances/%s_ohs_instance%/config/OHS/%s_ohs_component%/proxy-wallet/cwallet.sso $FMW_Home/webtier/instances/%s_ohs_instance%/config/OPMN/opmn/wallet/cwallet.sso $FMW_Home/user_projects/domains/%s_wls_domain_name%/opmn/%s_ohs_instance%/%s_ohs_component%/wallet/cwallet.sso $FMW_Home/user_projects/domains/%s_wls_domain_name%/opmn/%s_ohs_instance%/wallet/cwallet.sso
Note: If you are making use of in-house or self-signed certificates, which requires updates to the cacerts file, you will also need to copy over the following two files:
$COMMON_TOP/util/jdk32/jre/lib/security/cacerts
$COMMON_TOP/util/jdk64/jre/lib/security/cacerts

5.3 Configure Loopback and Outbound Connections

This section provides instructions for configuring TLS for loopback and outbound connections. The instructions cover:

Enabling TLSv1.1 and TLSv1.2 in the Java HTTPS clients (if your Java version does not already do so by default). [Step 1]
Updating client truststores (if required). [Steps 2 and 3]

5.3.1 Perform the General Required Configuration

Step 1 - Update the AdminServer and the Managed Server (WLS) Configuration
Note: If you have NOT already applied the April 2017 or later JDK patch to your application tier, then you will also need to add the -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 parameter. The JDK April 2017 patch and later do not require this additional parameter.
If you are configuring Oracle E-Business Suite Release 12.2 to use TLS 1.2 only, the value to use for all managed servers and the WebLogic administration server will differ. Refer to "Configure Loopback and Outbound Connections" in 6.1 Configure TLS 1.2 Only for details.
Append the following JVM parameter to all managed servers:
Log in to Oracle Fusion Middleware Administration Console (for example, http://<hostname>.<domain>:<AdminServer Port>/console)
Click on Lock & Edit.
Under Domain Structure > your Oracle E-Business Suite domain > Environment and Servers, select one of the managed servers. (Note that you will need to repeat this for all managed servers in your environment.)
Then under the Server Start tab in the Arguments section, add the following:
-DUseSunHttpHandler=true
Click on Save.
Repeat steps 3 and 4 for all remaining managed servers.
For each of the managed servers and the AdminServer, under the SSL tab, click on Advanced, and set the Hostname Verification to Custom Hostname Verifier and the Custom Hostname Verifier field to weblogic.security.utils.SSLWLSWildcardHostnameVerifier.
Click on Activate Changes.
Refer to the instructions in "4.2.1 Customizing Managed Server Configuration via WebLogic Server Administration Console" in Document 1905593.1, Managing Configuration of Oracle HTTP Server and Web Application Services in Oracle E-Business Suite Release 12.2 for more details.
For the WebLogic administration server, add the JVM parameter to the s_nm_jvm_startup_properties context variable.
Refer to the instructions in "Section 5: Updating the Classpath and JVM Arguments of the WebLogic AdminServer" in Document 1905593.1, Managing Configuration of Oracle HTTP Server and Web Application Services in Oracle E-Business Suite Release 12.2 for more details.
Step 2 - Update the b64InternetCertificate.txt Truststores
Add the contents of the ca.crt file to b64InternetCertificate.txt file.
If you need to import the CA Certificate, you will also need to add the contents of the ca.crt file to the b64InternetCertificate.txt file located in the 10.1.2 ORACLE_HOME/sysman/config directory:
$ cat ca.crt >> <10.1.2 ORACLE_HOME>/sysman/config/b64InternetCertificate.txt
If using a CA-signed ECC certificate, perform the previous step. If using a self-signed ECC certificate, perform the following:
$ cd <s_web_ssl_directory>/Apache $ $FMW_HOME/oracle_common/bin/orapki wallet export -wallet ./ -dn "CN=<hostname.domainname>" -cert ca_selfsigned.cert –jsafe $ cat ca_selfsigned.cert >> <10.1.2 ORACLE_HOME>/sysman/config/b64InternetCertificate.txt
Step 3 - Update the cacerts Truststore
If you purchased your server certificate from a commercial CA, you will most likely not have to perform this step as the root CA certificate will already be present in cacerts. The keytool command will let you know if you attempt to add a certificate already present in cacerts. In the case of in-house and/or self-signed certificates, this step will be required.
Note: Whenever you upgrade your JDK version on the server, any additional certificate you added to your cacerts file will be lost. You will need to re-import the root certificate or keep a copy of your original cacerts file which you can copy back in.
Update the JDK cacerts file.
Oracle Web Services requires the certificate of the certifying authority who issued your server certificate (ca.crt from the previous step) to be present in the JDK cacerts file. In addition, some features of XML Publisher and BI Publisher require the server certificate (server.crt from previous step) to be present.
Navigate to the <s_fmw_jdktop>/jre/lib/security directory. Refer to the Application context file for the exact location of the <s_fmw_jdktop> variable.
Follow these steps to ensure these requirements are met:
Backup the existing cacerts file.
Copy your ca.crt file to this directory and issue the following command to ensure that cacerts has write permissions:
$ chmod u+w cacerts
Add your Apache ca.crt to cacerts:
$ keytool -import -alias ApacheRootCA -file ca.crt -v -keystore cacerts
When prompted, enter the keystore password. See The cacerts Certificates File, keytool.
When you have completed the modifications to the cacerts, reset the permissions:
$ chmod u-w cacerts
If using a CA-signed ECC certificate, perform the same step above. If using a self-signed ECC certificate, perform the following:
$ cp <s_web_ssl_directory>/Apache/ca_selfsigned.cert <s_fmw_jdktop>/jre/lib/security $ chmod u+w cacerts $ keytool -import -alias selfca -file ca_selfsigned.cert -v -keystore cacerts $ chmod u-w cacerts
Note: For Oracle E-Business Suite Release 12.2 installations that use 64-bit JDK for Oracle Fusion Middleware, the steps in this section must be repeated for the 32-bit JDK keystore location that is still in use by some products. If the Application context file <s_fmw_java_use_64> variable is set to 'true', then repeat the steps for the 32-bit cacerts in $OA_JRE_TOP/lib/security. Some UNIX platforms such as Oracle Solaris have a single JDK location.

5.3.2 Database Tier Setup

Oracle products such as Oracle Configurator, Order Management, Order Capture, Quoting, iPayment, iStore, and Pricing are leveraging the database as an HTTP client. The implementation of TLS for the Oracle Database Server (which acts as a client sending requests to the web server) makes use of the Oracle Wallet Manager for setting up an Oracle wallet.

Note: This is a mandatory requirement for Oracle iStore storefront pages when the web tier is TLS enabled.

To enable the HTTPS client request from the database using UTL_HTTP, you need to establish a truststore in wallet format. You do not need a server certificate for this wallet. You only need to import the root CA certificate for the root CAs that are the trust anchor for the sites you need UTL_HTTP to connect to.

After setting your environment for the database tier, navigate to the $ORACLE_HOME/appsutil directory.
Create a new wallet directory named wallet.
Navigate to the newly created wallet directory.

For self-signed ECC cert:

cp <s_web_ssl_directory>/Apache/ca_selfsigned.cert $ORACLE_HOME/appsutil/wallet

Follow the rest of steps to import this cert into database wallet directory using owm utility.

Open the Oracle Wallet Manager as a background process.
$ owm &
In the Oracle Wallet Manager Menu, navigate to Wallet, then New.
Answer NO to: Your default wallet directory doesn't exist. Do you wish to create it now? The new wallet screen will now prompt you to enter a password for your wallet. Click NO when prompted: A new empty wallet has been created. Do you wish to create a certificate request at this time?
If you need to import ca.crt, on the Oracle Wallet Manager menu:
1. Navigate to Operations, then Import Trusted Certificate.
2. Click OK.
3. Double click on ca.crt to import it.
Save the wallet:
1. On the Oracle Wallet Manager Menu, click Wallet.
2. Verify the Auto Login check box is selected.
3. Click Save.

If you are using CA-signed ECC certificates, follow the steps below:

After setting your environment for the database tier, navigate to the $ORACLE_HOME/appsutil directory.
Create a new wallet directory named wallet.
Create an auto login wallet.
$ orapki wallet create -wallet . -auto_login -pwd <PASSWORD>
Import Trusted CA cert ca.crt into the wallet.
$ orapki wallet add -wallet . -trusted_cert -cert ca.crt -pwd <PASSWORD> -jsafe
Command to display and verify the content of the wallet.
$ orapki wallet display -wallet . -jsafe

To test that the wallet is properly set up and accessible, log in to SQLPLUS as the APPS user and execute the following:

SQL> select utl_http.request('[address to access]', '[proxy address]', 'file:[full path to wallet directory]', null) from dual;

where:

'[address to access]' = the URL for your Oracle E-Business Suite Rapid Install Portal.

'[proxy address]' = the URL of your proxy server, or NULL if not using a proxy server.

'file:[full path to wallet directory]' = the location of your wallet directory (do not specify the actual wallet files)

The final parameter is the wallet password, which is set to null by default.

Examples:

SQL> select utl_http.request('https://hostname.example.com/test.htm','http://proxyhost.example.com:80', 'file:/d1/oracle/db/tech_st/12.1.0/appsutil/wallet', null) from dual;

SQL> select utl_http.request('https://hostname.example.com',null, 'file:/d1/oracle/db/tech_st/12.1.0/appsutil/wallet', null) from dual;

If the wallet has been properly set up, you will be returned the first 2,000 characters of the HTML page.

A potential caching issue with the Database wallet may or may not be encountered. Even though the utl_http.request returns the expected value, a "Certification Validation Failure" error message appears in the logs. The corrective action for this involves moving the wallet directory to a new location and reset the Oracle E-Business Suite profile option "Database Wallet Directory" to the new location.

Note: Oracle Database 12c and Oracle Database 11g Release 2 (11.2) enables Oracle Real Application Clusters (Oracle RAC) nodes to share a wallet. This eliminates the need to manually copy and synchronize the wallet across all nodes. The wallet can be created on a shared file system, allowing all instances to access the same shared wallet. If you are not using a shared file system to store the wallet, you need to copy the wallet to all nodes. This also applies to advanced database security features for which you may already be using a wallet, such as Transparent Data Encryption.

The steps in this section can also be used with Oracle Database 19c.

5.4 Enable TLS for WLS AdminServer

Oracle Fusion Middleware provides a comprehensive security infrastructure detailed in the Security for Oracle Fusion Middleware Documentation Library, including configuring TLS in Oracle Fusion Middleware on securing the internal communication between Oracle WebLogic Server, Oracle HTTP Server, and other components. Oracle E-Business Suite Release 12.2 currently supports securing the communication between the user's browser and Oracle HTTP Server. The procedure outlined in this section will configure SSL or TLS for the Oracle WebLogic AdminServer using the same certificate generated in the previous steps as the Oracle HTTP Server and Oracle WebLogic server resides on the same host. Information for optional configurations on enabling TLS for WLS managed servers can be found in in 6.3 Enable TLS for WLS Managed Server.

Additional information can be referenced in Oracle Fusion Middleware Securing Oracle WebLogic Server 10.3.6, specifically in the area of security for WLS. By default, the WLS implemented with OHS/Webtier 11.1.1.9 makes use of the Java Secure Socket Extension (JSSE) based SSL implementation.

5.4.1 Required Patches

This configuration requires AD/TXK delta 9 at a minimum. Refer to Document 1617461.1, Applying the Latest AD and TXK Release Update Packs to Oracle E-Business Suite Release 12.2, if not already done.

5.4.2 Configuration

WebLogic (10.3.6) supports four types of keystores:

Custom Identity and Custom Trust
Custom Identity and Command Line Trust
Custom Identity and Java Standard Trust
Demo Identity and Demo Trust

By default WebLogic servers (AdminServer) are configured with demo identity and trust information. We currently support the change from the default "Demo Identity and Demo Trust" to "Custom Identity and Custom Trust". To use real or self-signed certificates, you must configure this setting as "Custom Identity and Custom Trust". The steps that follow involve the use of a real certificate and assume that the Oracle E-Business Suite has already been configured for TLS with a valid production certificate.

Step 1 - Setup a WebLogic Server Identity Keystore
On the WLS Admin node as the applmgr user, create the wlsSSLArtifacts directory:
Source the run file system environment.
Create a new directory named wlsSSLArtifacts.
$ mkdir -p <NE_BASE>/inst/<CONTEXT_NAME>/wlsSSLArtifacts
Copy the existing Oracle wallet files from the <s_web_ssl_directory>/Apache directory to the wlsSSLArtifacts directory.
The file ewallet.p12 contains all the certificate information from the wallet created in Section 5.

Customers who created the ECC wallet using the auto_login_only option - as shown in Section "5.2 Configure Inbound Connections" Step 2 - "Create a wallet" - will not have a ewallet.p12 file. Instead copy the cwallet.sso file to the wlsSSLArtifacts directory.
Copy the <s_fmw_jdktop>/jre/lib/security/cacerts to the wlsSSLArtifacts directory.
Note: Whenever you upgrade your JDK version on the server, any additional certificate you added to your cacerts file will be lost. You will need to re-import the root certificate or keep a copy of your original cacerts file which you can copy back in.
Step 2 - Convert the Oracle Wallet to a JKS Keystore
The steps that follow are done from the wlsSSLArtifacts directory. Additional information can be found in the Oracle Fusion Middleware Administrator's Guide 11g Release 1 (11.1.1) under H.1.6 Converting Between Oracle Wallet and JKS Keystore.
Set the environment:
$ . $FMW_HOME/user_projects/domains/<EBS_domain>/bin/setDomainEnv.sh
Run the orapki command:
$ $FMW_HOME/oracle_common/bin/orapki wallet pkcs12_to_jks -wallet ./ -pwd <PASSWORD> -jksKeyStoreLoc ./ewallet.jks -jksKeyStorepwd <NEW_PASSWORD>
The first password is the password used when the wallet was initially created. The second password is a new password you provide and used in the steps that follow.

If using an ECC certificate, perform the following:
$ cd <NE_BASE>/inst/<CONTEXT_NAME>/wlsSSLArtifacts $ $FMW_HOME/oracle_common/bin/orapki wallet pkcs12_to_jks -wallet ./ -jksKeyStoreLoc ./ewallet.jks -jksKeyStorepwd <PASSWORD> –jsafe
The ewallet.jks file generated will be referenced in the steps that follow.
Extract the alias from the keystore using this command:
$ keytool -list -keystore ewallet.jks -v
The alias will correspond to the primary certificate issued. For example orakey is generally the default alias name. Make a note of the alias as it will be needed for the next step.
Step 3 - Configure SSL on WLS
Take a backup of $EBS_DOMAIN_HOME/config/config.xml file.
Use the adstpall.sh script to stop everything on the run file system, and then start only the AdminServer using adadminsrvctl.sh script. When enabling SSL for the AdminServer, it needs to be in RUNNING state.
In the WebLogic Server Administration Console, under the Domain Structure, click on Environment and Servers.
If you are running in production mode, click Lock & Edit.
Click on the AdminServer to configure.
Under the Configuration tab, click on the Keystores sub-tab.
Click Change next to the Keystores setting.
Select the Custom Identity and Custom Trust option and click Save.
Enter the identity details. For example:
Custom Identity Keystore: <NE_BASE>/inst/<CONTEXT_NAME>/wlsSSLArtifacts/ewallet.jks
(This corresponds to the full path of the ewallet.jks file created previously in Step 2.)
Custom Identity Keystore Type: JKS (This must be in uppercase.)
Custom Identity Keystore Passphrase: This must match the password used from the orapki command previously in Step 2.
Confirm Custom Identity Keystore Passphrase
Enter the trust information. For example:
Custom Trust Keystore: <NE_BASE>/inst/<CONTEXT_NAME>/wlsSSLArtifacts/cacerts
Custom Trust Keystore Type: JKS
Custom Trust Keystore Passphrase: Enter the cacerts keystore password. See The cacerts Certificates File, keytool.
Confirm Custom Trust Keystore Passphrase: Confirm the cacerts keystore password.
Click Save.
Click the SSL tab.
Enter the identity details. For example.
Private Key Alias: orakey. This would correspond to the alias extracted from the keystore previously in Step 2.
Private Key Passphrase: This must match the password used from the orapki command previously in Step 2.
Confirm Private Key Passphrase
Click Save.
Click the General tab.
Select SSL Listen Port Enabled check box.
Enter the SSL Listen Port.
Note: The SSL Listen Port base values are available through the context variable s_wls_admin_sslport. Based on the server type, you need to choose the corresponding port value for the SSL Listen Port. You need to manually calculate SSL Listen Port value. For simplicity, the default SSL Listen port value is 1 prefixed with the server default Non SSL Listen port value.
For example, for port pool 0, the AdminServer Non SSL Listen port is 7001, so the AdminServer SSL Listen port will be 17001.
Click Save.
Select the SSL tab.
Select the Advanced option and then perform the following:
Set the Hostname Verification to Custom Hostname Verifier and the Custom Hostname Verifier field to weblogic.security.utils.SSLWLSWildcardHostnameVerifier
Click Save.
Click Activate Changes.

5.4.3 Post-Configuration Tasks

Step 1 - Restart
Edit the corresponding <EBS_DOMAIN_NAME>/servers/AdminServer/data/nodemanager/boot.properties file and comment out the TrustKeyStore=DemoTrust line, if the boot.properties file exists. Since this configuration changes the Keystore setting from the default 'Demo Identity and Demo Trust' to 'Custom Identity and Custom Trust', the parameter in the boot.properties does not reflect this change. Restarting everything without making this change will cause the AdminServer to not start on the SSL port.
Restart everything including the Admin and Managed Servers using the adstpall.sh and adstrtal.sh scripts. Ensure that everything started up successfully.
Step 2 - Sync Changes to the Context File
Run the following command:
$ perl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE
After SSL enablement for the AdminServer, the adSyncContext.pl script execution will populate the following context variables in the context file:
s_custom_trustKeyStoreFile - complete path of trust keystore
s_wls_admin_sslEnabled - true
s_wls_admin_sslport - AdminServer SSL port
In the case where these listed context variables are not already populated, restart the middle tier services and re-run the following command:
$ perl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE
If this step is not completed, the fs_clone process will fail.
Step 3 - Final Restart and Running fs_clone
Run AutoConfig via the adautocfg.sh script.
Restart everything including the Admin and Managed Servers using the adstpall.sh and adstrtal.sh scripts. Ensure that everything started up successfully.
Run adop phase=fs_clone to sync up the run and patch file system.
Should the fs_clone fail, go back and review all steps in Section 5.4 and confirm everything is correct.
This completes Section 5: Enable TLS 1.2 with Backward Compatibility. All changes made to the run file system up to this point will get propagated to the patch file system as part of the next patching cycle. If you wish to propagate these changes to the current patch file system immediately, you can do so using the fs_clone operation (adop phase=fs_clone) so that both run and patch file systems are in sync.
Note: If you are running Oracle HTTP Server on a privileged port, you must perform additional steps when running an online patching cycle. For detailed steps, see "Requirements When Running Oracle HTTP Server on a Privileged Port" in the Oracle E-Business Suite Maintenance Guide.

Section 6: Optional Configurations

This section provides the steps required to implement optional configurations. To implement any one of these alternatives, you must have already completed the steps previously described in Section 5: Enable TLS 1.2 with Backward Compatibility.

6.1 Configure TLS 1.2 Only
6.2 Disable the HTTP Port
6.3 Enable TLS for WLS Managed Server
6.4 HTTP Strict Transport Security (HSTS)
6.5 Configuration for Forward Secrecy

6.1 Configure TLS 1.2 Only

You may optionally configure Oracle E-Business Suite to use only the highest level of TLS certified with Oracle E-Business Suite Release 12.2.

This section provides the steps required to configure Oracle E-Business Suite Release 12.2 to use TLS 1.2 only.

Attention:

If you configure Oracle E-Business Suite Release 12.2 to use TLS 1.2 only, this configuration could result in the inability to connect to other sites or browsers that do not support TLS 1.2.
You should not configure Oracle E-Business Suite Release 12.2 to use TLS 1.2 only if you intend to use either Mobile Applications V5 or Oracle E-Business Suite Information Discovery V6 as these only support TLS 1.0.

6.1.1 Prerequisites

To configure Oracle E-Business Suite Release 12.2 to use TLS 1.2 only, you must ensure that you not only meet the requirements listed in the previous sections of this document, but that you fulfill the following additional requirements:

Upgrade Oracle Database
Perform either of the following to enable TLS 1.2 support for Oracle Database:
- Upgrade to Oracle Database 12.1.0.2 following the instructions in My Oracle Support Knowledge Document 1926201.1, Interoperability Notes Oracle E-Business Suite Release 12.2 with Oracle Database 12c Release 1 (12.1.0).
- Upgrade to Oracle Database 11.2.0.4 following the instructions in My Oracle Support Knowledge Document 1623879.1, Interoperability Notes Oracle E-Business Suite Release 12.2 with Database 11g Release 2 (11.2.0.4).
  
  Note: For customers using Oracle Database 11.2.0.4, it is required to apply a supported version of Database PSU which is OCT PSU 2018 or later (see MOS Document 1147107.1, Database Patch Set Update Overlay Patches Required for Use with PSUs and Oracle E-Business Suite).

Configure Java Runtime Environment on the Desktop Client
Ensure that your desktop client has either:
- JRE 8 - TLS 1.2 enabled by defaul,t; or
- JRE 6/7 - Starting with the January 2017 JAVA CPU, TLS 1.1 and TLS 1.2 are enabled by default. The specific minimum versions are JRE 1.6.0_141 and JRE 1.7.0_131.
  
  Note: For any JRE 6/7 version older than Jan '17 CPU, TLS 1.2 can be enabled in JRE 6/7 through the Java Control Panel by navigating to Java Control Panel, Advanced tab, Advanced Security Settings section, Use TLS 1.2.
Use a TLS-Supported Browser
Currently supported Windows browsers are as follows, with TLS 1.2 enabled by default:
- Microsoft Internet Explorer 11
- Mozilla Firefox ESR 45.x
- Google Chrome v49

6.1.2 Configure Inbound Connections

To configure Oracle E-Business Suite Release 12.2 to use TLS 1.2 only for inbound connections, you must basically follow all steps listed in 5.2 Configure Inbound Connections, although in step 7 and step 9, there are minor changes required.

Alternate 5.2 Step 7 - Modify the OPMN Wallet and Configure the Cipher Suites:

3. Edit the opmn.xml file.
Change:
<ssl enabled="true"      wallet-file="<path to the wallet file>"/>
to
<ssl enabled="true"     wallet-file="<Path to the Wallet file>" ssl-versions="TLSv1.2"     ssl-ciphers="<Pick two ciphers from the list of valid ciphers below,separated by a comma>"/>
The following list specifies the valid cipher suites that can be used:
SSL_RSA_WITH_AES_256_CBC_SHA
SSL_RSA_WITH_AES_128_CBC_SHA
For example:
<ssl enabled="true"     wallet-file="/EBS_web_EBSDB_OHS1/config/OPMN/opmn/wallet" ssl-versions="TLSv1.2" ssl-ciphers="SSL_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_AES_128_CBC_SHA"/>

If using an ECC certificate, no need to specify any ciphers. You can remove the ssl-ciphers line from opmn.xml.
4. Edit the admin.conf file.
Change:
SSLCipherSuite SSL_RSA_WITH_RC4_128_SHA SSLProtocol nzos_Version_1_0 nzos_Version_3_0
to
SSLCipherSuite SSL_RSA_WITH_AES_256_CBC_SHA:SSL_RSA_WITH_AES_128_CBC_SHA SSLProtocol nzos_Version_1_2
If using an ECC certificate, no need to specify any ciphers. You can comment out the SSLCipherSuite line.

Alternate 5.2 Step 9 - Update the Context File and Config Files:

6. Update the SSLProtocol and SSLCipherSuite entry to match the following:
SSLProtocol TLSv1.2 SSLCipherSuite HIGH:MEDIUM:!aNULL:!RC4:!3DES:!SEED:!IDEA:!CAMELLIA:+HIGH:+MEDIUM
If using an ECC certificate, no need to specify any ciphers. You can comment out the SSLCipherSuite line.

6.1.3 Configure Loopback and Outbound Connections

Note: If you have applied the April 2017 or later JDK patch to your application tier, then you can skip this step.

To configure Oracle E-Business Suite Release 12.2 to use TLS 1.2 only for loopback and outbound connections, follow the steps in 5.3 Configure Loopback and Outbound Connections. The only difference is found in Step 1 where you need to update all managed servers and the WebLogic administration server with the value below:

Alternate 5.3 Step 1 - Update the Managed Server (WLS) Configuration:

3. Under Domain Structure > your Oracle E-Business Suite domain > Environment and Servers, select one of the managed servers. (Note that you will need to repeat this for all managed servers in your environment.)

Then under the Server Start tab in the Arguments section, add the following:
-Dhttps.protocols=TLSv1.2
For the WebLogic administration server, add the JVM parameter to the s_nm_jvm_startup_properties context variable.
Refer to the instructions in "Section 5: Updating the Classpath and JVM Arguments of the WebLogic AdminServer" in Document 1905593.1, Managing Configuration of Oracle HTTP Server and Web Application Services in Oracle E-Business Suite Release 12.2 for more details.

6.2 Disable the HTTP Port

You may optionally configure Oracle E-Business Suite to disable the HTTP port and use the HTTPS port only. Although this configuration is optional, we strongly recommend that you implement the configuration in this section and disable the HTTP only port. If the currently defined HTTP port value is that of a privileged port then it must be either disabled or changed to a non-privileged value to avoid errors during ADOP clone operations.

Note: There is a known issue when disabling the HTTP port and use of in-house or self-signed certificates. Until this can be addressed, customers making use of these type of certificates should not disable the HTTP port.

6.2.1 Required Patches

To disable the HTTP port, the following patch is required:

Oracle Fusion Middleware Patch 22288381

Note: When downloading this patch, select the 'Oracle Global Lifecycle Management Test to Production' option, as the option for 'Oracle Fusion Middleware' cannot be downloaded. For more information, see Document 2142774.1 FMW Patch 22288381: This Patch is Obsolete. It cannot be Downloaded.

6.2.2 Configuration Changes

Log in to the Oracle Fusion Middleware Control Console (http://<hostname>.<domain>:<AdminServer Port>/em).
Select the web tier target under the EBS domain.
Click on the EBS_web_<SID> and the Oracle HTTP Server drop down.
Select Administration, then Advanced Configuration.
Select httpd.conf file for edit and click Go.
Search for Listen parameter and comment it or disable it (for example, #Listen 8000)
Switch the order of the following include statements such that the ssl.conf comes before the admin.conf:
# Include the SSL definitions and Virtual Host container include "${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/ssl.conf" # Include the admin virtual host (Proxy Virtual Host) related configuration include "${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/admin.conf"
Click Apply and restart the OPMN services for the change to take effect.

If you are using ECC certificates, due to known issue bug 26493558, you will need to edit the ssl.conf file manually from the command line.

Note: There is a known issue documented in bug 20472035 initially found for 12.1, but also affects 12.2. As a workaround until TXK bug 21969510 is addressed, you can set the profile 'Applications Help Web Base URL' to null at the site level in your environment. This would be the only workaround until a permanent fix is provided by TXK bug 21969510. You will also need to remember to set this back to null after any AutoConfig run.

6.3 Enable TLS for WLS Managed Server

Oracle Fusion Middleware provides a comprehensive security infrastructure detailed in the Security for Oracle Fusion Middleware Documentation Library, including configuring TLS in Oracle Fusion Middleware on securing the internal communication between Oracle WebLogic Server, Oracle HTTP Server, and other components. Oracle E-Business Suite Release 12.2 currently supports securing the communication between the end user's browser and Oracle HTTP Server. You can also secure the internal communication between Oracle HTTP Server and Oracle WebLogic managed servers by following the procedures outlined in this section. This configuration is considered optional and will configure SSL/TLS for the managed servers using the same certificate generated in the procedures previously as the Oracle HTTP Server and Oracle WebLogic server resides on the same host.

Additional information can be referenced in the Oracle Fusion Middleware documentation guide, specifically in the area of security for WLS. By default, the WLS implemented with OHS/Webtier 11.1.1.9 makes use of the Java Secure Socket Extension (JSSE) based SSL implementation.

6.3.1 Configuration

You will have already completed the steps outlined in 5.4 Enable TLS for WLS AdminServer, as the steps in this section rely on making use of the same keystore.

Oracle WebLogic Server (10.3.6) supports four types of keystores:

Custom Identity and Custom Trust
Custom Identity and Command Line Trust
Custom Identity and Java Standard Trust
Demo Identity and Demo Trust

By default, WebLogic servers (Managed Server) are configured with demo identity and trust information. We currently support the change from the default "Demo Identity and Demo Trust" to "Custom Identity and Custom Trust". This needs to be reconfigured to use real or self-signed certificates. The steps that follow involve the use of a real certificate and assume that the Oracle E-Business Suite has already been configured for TLS with a valid production certificate.

Configure SSL on WLS

Take a backup of $EBS_DOMAIN_HOME/config/config.xml file.
For any ManagedServer before enabling SSL, ensure that the ManagedServer is already in SHUTDOWN state. Otherwise after enabling SSL for the first time, the ManagedServer running in SSL mode may not be stopped using the control script.
In the WebLogic Server Administration Console, under Domain Structure, click on Environment and Servers.
If you are running in production mode, click Lock & Edit.
Click on the server you wish to configure.
Under the Configuration tab, click on the Keystores sub-tab.
Click Change next to the Keystores setting.
Select the Custom Identity and Custom Trust option and click Save.
Enter the identity details. For example:
- Custom Identity Keystore: <NE_BASE>/inst/<CONTEXT_NAME>/wlsSSLArtifacts/ewallet.jks (This corresponds to the full path of the ewallet.jks file created previously in Section 5.4 Enable TLS for WLS AdminServer).
- Custom Identity Keystore Type: JKS (This must be in uppercase)
- Custom Identity Keystore Passphrase: This password must match the password used from the orapki command previously in Section 5.4 Enable TLS for WLS AdminServer.
- Confirm Custom Identity Keystore Passphrase
Enter the trust information. For example:
- Custom Trust Keystore: <NE_BASE>/inst/<CONTEXT_NAME>/wlsSSLArtifacts/cacerts
- Custom Trust Keystore Type: JKS
- Custom Trust Keystore Passphrase: Enter the cacerts keystore password. See The cacerts Certificates File, keytool.
- Confirm Custom Trust Keystore Passphrase: Confirm the cacerts keystore password.
Click Save.
Click the SSL tab.
Enter the identity details. For example.
- Private Key Alias: orakey (This would correspond to the alias extracted from the keystore previously in Section 5.4 Enable TLS for WLS AdminServer.)
- Private Key Passphrase: This must match the password used from the orapki command previously in Section 5.4 Enable TLS for WLS AdminServer.
- Confirm Private Key Passphrase
Click Save.
Select the General tab.
Select SSL Listen Port Enabled check box.
Enter SSL Listen Port
Note: The SSL Listen Port base values are available via context variable s_wls_oacore_sslport, s_wls_forms_sslport, s_wls_oafm_sslport, s_wls_oaea_sslport. Based on the server type, you need to choose the corresponding port value for the SSL Listen Port. If an instance has multiple entries for the same type of ManagedServers, you need to manually calculate SSL Listen Port value for each ManagedServer. For simplicity for any server, the default SSL Listen port value is 1 prefixed with the server default Non SSL Listen port value.
- For example, for port pool 0, the managed server oacore_server1 Non SSL Listen port is 7201, so the SSL Listen port will be 17201.
Click Save.
Select the SSL tab.
Select Advanced option and perform the following:
- Set the Hostname Verification to Custom Hostname Verifier and the Custom Hostname Verifier field to weblogic.security.utils.SSLWLSWildcardHostnameVerifier
- Click Save.
For each of the managed servers:
- Under the Domain Structure and Environment, click Clusters.
- Select ManagedServer specific cluster name and select the Replication tab.
- Check the check box beside Secure Replication Enabled option.
- Click Save.
(Optional) In case you wish to disable the non-SSL port, then you need to follow these steps after enabling "SSL Listen Port" and before restarting the server.
Unselect the Listen Port Enabled check box. Otherwise after SSL enablement, the server will be listening on both the non SSL port as well as the SSL listen port. As of now this optional step of disabling non SSL port is applicable only for the ManagedServer, but not for AdminServer. Currently for MBean server connection, the t3 protocol is used in all technology stack and cloning code. If you disable the non-SSL port listening on the AdminServer, then t3 and http protocols will stop working requiring the use of t3s and https protocols instead.
Click Activate Changes.

6.3.2 Post Configuration

Step 1 - Restart
For each of the managed servers, edit the corresponding <EBS_DOMAIN_NAME>/servers/<managedServerName>/data/nodemanager/boot.properties file and comment out the TrustKeyStore=DemoTrust line, if the boot.properties file exists. Since this configuration changes the Keystore setting from the default 'Demo Identity and Demo Trust' to 'Custom Identity and Custom Trust', the parameter in the boot.properties does not reflect this change. Restarting everything without making this change will cause the managed servers to not start and show a status of FAILED_NOT_RESTARTABLE.
Restart everything including the Admin and Managed Servers using the adstpall.sh and adstrtal.sh scripts. Ensure that everything started up successfully.
Step 2 - Sync up changes to the context file
Run the following command:
$ perl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE
After SSL enablement for the ManagedServer, the adSyncContext.pl script execution will populate the following context variables in the context file:
s_<ManagedServerType>_server_sslports - <ManagedServerName>:<ManagedServerPort>
In the case where the previously mentioned context variable is not already populated, restart the middle tier services and re-run the command:
$ perl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE
If this step is not completed, the fs_clone process will fail.
Step 3 - Add/Remove the managed server port information
On the run file system after completing SSL enablement at the Managed Server level, you need to execute the txkSetAppsConf.pl script with the addMS option by providing current managedServer ListenAddress and SSLListen port information. This will add the managedServer ListenAddress and SSL Listen Port information into OHS configuration files for the managed servers that you have now SSL enabled. Refer to Document 1905593.1 Managing Configuration of Oracle HTTP Server and Web Application Services in Oracle E-Business Suite Release 12.2, for more information on the command.
$ perl $FND_TOP/patch/115/bin/txkSetAppsConf.pl \ -contextfile=$CONTEXT_FILE \ -configoption=addMS \ -oacore=<host>.<domain>:<port> \ -oafm=<host>.<domain>:<port> \ -forms=<host>.<domain>:<port> \
The argument contextfile accepts the complete path to the context file. The arguments oacore, oafm, forms accept a comma-separated list of managed server details in the following format:
<host>.<domain>:<port>
Host and domain are the hostname and domain name of the newly added node.
Port is the port of the new managed server whose reference is to be added.
For example, if you have only enabled the oacore_server1 and oafm_server1:
$ perl $FND_TOP/patch/115/bin/txkSetAppsConf.pl \ -contextfile=$CONTEXT_FILE \ -configoption=addMS \ -oacore=hostname.example.com:17202 \ -oafm=hostname.example.com:17602
This only needs to be performed in the case where in Step 3 - Configure SSL on WLS, #22 above, you have opted to disable the non-SSL ports. Execute the txkSetAppsConf.pl script with the removeMS option by providing the earlier managedServer ListenAddress and non SSLListen port information. This will remove the earlier managedServer ListenAddress and Non SSL Listen Port information from OHS configuration files.
$ perl $FND_TOP/patch/115/bin/txkSetAppsConf.pl \ -contextfile=$CONTEXT_FILE \ -configoption=removeMS \ -oacore=<host>.<domain>:<port> \ -oafm=<host>.<domain>:<port> \ -forms=<host>.<domain>:<port> \
The argument contextfile accepts the complete path to the context file. The arguments oacore, oafm, forms accept a comma-separated list of managed server details in the following format:
<host>.<domain>:<port>
Host, domain and port are the hostname, domain and port of the managed server whose reference is to be deleted.

For example, if you have only enabled the oacore_server1 and oafm_server1:
$ perl $FND_TOP/patch/115/bin/txkSetAppsConf.pl \ -contextfile=$CONTEXT_FILE \ -configoption=removeMS \ -oacore=hostname.example.com:7202 \ -oafm=hostname.example.com:7602

Step 4 - Modify the mod_wl_ohs.conf file
Use the Oracle Fusion Middleware Control Console and follow the steps below to make changes to the configuration file.
Log in to Oracle Fusion Middleware Control Console (for example, http://<hostname>.<domain>:<AdminServer Port>/em).

Select Web Tier Target under EBS Domain.

Select Administration > Advanced Configuration.

Select mod_wl_ohs.conf file for edit.

Go to the ManagedServer specific Location directive as per the following:
For the oacore type ManagedServer Location directive, the context root is /OA_HTML.
For the forms type ManagedServer Location directive, the context root is /forms.
For the oafm type ManagedServer Location directive, the context root is /webservices.
For the oaea type ManagedServer ekanban application Location directive, the context root is /ekanban-UI-context-root.
For the oaea type ManagedServer accessgate application Location directive, the context root is /accessgate.
For the oaea type ManagedServer YMS application Location directive, the context root is /YMS-UI-context-root.

Each Location directive contains the below SSL-related attributes:
#SecureProxy ON
#WLProxySSL ON
#WLSSLWallet "${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/keystores/default"

Uncomment these attributes for the ManagedServer type for which you ran the addMS option in an earlier step, by removing the hash (#) sign for each line.

Click Apply.
Step 5 - Final restart and running fs_clone
Run AutoConfig by using the adautocfg.sh script.
Restart everything including the Admin and Managed Servers using the adstpall.sh and adstrtal.sh scripts. Ensure that everything started up successfully.
Run adop phase=fs_clone to sync up the run and patch file system.
Should the fs_clone fail, go back and review all steps in 6.3 Enable TLS for WLS Managed Server and confirm everything is correct.

6.4 HTTP Strict Transport Security (HSTS)

You may optionally configure Oracle E-Business Suite to enable HTTP Strict Transport Security which instructs web browsers to only use secure connections for future requests when communicating with a web site.

This feature should be configured at the TLS termination point (for example: Oracle HTTP Server (OHS), Load-balancer). The max_age parameter allows you to specify a time period (in seconds) that browsers will communicate using only HTTPS. When testing HSTS, start the configuration using short time periods, for example, 15 minutes. When deploying to production a long value should be used, recommended values are in the range 6 to 12 months.

Once the HSTS header is configured and the browser has visited the HTTPS port, you won’t be able to access that server using HTTP. Browsers will rewrite the URL to HTTPS if the user attempts to connect via HTTP, but the rewrite will not change the port number. The rewriting will only work if the URL does NOT contain a port number.

To configure HSTS:

Log in to Oracle Fusion Middleware Control Console (for example, http://<hostname>.<domain>:<AdminServer Port>/em).
Select Web Tier Target under the EBS Domain.
Select Administration, then Advanced Configuration.
Select ssl.conf file for edit.
Add the following line at the end of the <VirtualHost_default_:%s_webssl_port%> block:
- Header set Strict-Transport-Security "max-age=31536000"
Click Apply.

If you are using ECC certificates, due to known issue Bug 26493558 you will need to edit the ssl.conf file manually from the command line.

Run AutoConfig using the adautocfg.sh script in the application tier $ADMIN_SCRIPTS_HOME directory.

Restart the application tier services using the adstpall.sh/adstrtal.sh script in the $ADMIN_SCRIPTS_HOME directory to stop and restart all services.

6.5 Configuration for Forward Secrecy

The general definition of Forward Secrecy (FS) is that it is an attribute of the specific key exchange mechanism in TLS security protocols that implies the independence of the session key generated during the secure session establishment from the set of long-term Public and Private keys and the session keys used in the previous sessions. The intent of the key exchange is to ensure that two parties will agree on a session key upon the security settings available for both participants of the secure negotiation and that no one else will know it.

When you use the RSA key exchange mechanism, it creates a link between the server’s key pair and the session key created for each unique secure session. Thus, if an attacker is ever able to get hold of the server’s private key, they can decrypt your SSL session and any saved SSL sessions. In contrast, when you enable Forward Secrecy (FS), there is no link between your server’s private key and each session key. If an attacker ever gets access to your server’s private key, the attacker cannot use the private key to decrypt any of your archived sessions, which is why it is also called “Perfect Forward Secrecy” (PFS).

6.5.1 Requirements

In order to implement FS, you will need to comply with the following requirements:

Configure for TLS 1.2 only.
Use an ECC-based certificate.
Apply the latest CPU patches:
- OSS Bundle Patch 11.1.1.9.190716 Patch 27047184
- OPMN Patch 23716938
- OHS 11.1.1.9.0 SPU for JanCPU2018 Patch 27301611
Use the following cipher list: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

6.5.2 Configuration

Edit the admin.conf file located under the $FMW_HOME/webtier/instances/<s_ohs_instance>/config/OHS/<s_ohs_component> directory.
Make the following changes:
SSLProtocol nzos_Version_1_2 SSLCipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
Save the changes.
Edit the ssl.conf file located under the $FMW_HOME/webtier/instances/<s_ohs_instance>/config/OHS/<s_ohs_component> directory.
Make the following changes:
SSLProtocol TLSv1.2 SSLCipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
Save the changes.
The following command should be run (on all application tier nodes) to propagate the changes made to the context file variables:
$ perl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE Enter the APPS user password: Enter the WebLogic AdminServer password:
For Windows:
C:\> perl %AD_TOP%\bin\adSyncContext.pl contextfile=%CONTEXT_FILE%
Review the adSyncContext.log for the changes that have been picked up and made to the context file.

Section 7: Configure Optional Integrations

The following sub-sections provide required steps for optional integrations.

7.1 Oracle Discoverer
7.2 Oracle E-Business Suite Information Discovery
7.3 Service Invocation Framework - SOA
7.4 Separate Certificates for Inbound and Outbound Communication

7.1 Oracle Discoverer

Discoverer users who enable TLS for Oracle E-Business Suite as per Section 5 must also enable TLS for Discoverer 11g.

Refer to the following documents:

Document 1380591.1, Using Discoverer 11.1.1 with Oracle E-Business Suite Release 12.2
Document 1359491.1, How to Configure SSL For Discoverer 11g
Oracle Fusion Middleware Configuration Guide for Oracle Business Intelligence Discoverer

7.2 Oracle E-Business Suite Information Discovery

Oracle E-Business Suite Information Discovery Release 12.2 V6 Studio Component only supports TLS 1.0 and does not support TLS 1.2.

Oracle E-Business Suite Information Discovery users who enable TLS for Oracle E-Business Suite (as documented in Section 5: Enable TLS 1.2 with Backward Compatibility) must also enable TLS for Oracle Endeca. For more information, see Document 2038186.1, DMZ and SSL Configuration Guide for Oracle E-Business Suite Information Discovery, Release 12.2 V6.

7.3 Service Invocation Framework - SOA

Required patching and configuration:

Apply Patch 22612527 with prerequisite Patch 13866584 to the FMW home.
Update the 32-bit JDK 7 under $OA_JRE_TOP with the Java Cryptography Extension (JCE) download. (If you have a JAN-2016 Java version that already includes JCE, you can skip this step.)
Update the 64-bit JDK 7 under the directory referenced by the s_fmw_jdktop context variable with the Java Cryptography Extension (JCE) download. (If you have a JAN-2016 Java version that already includes JCE, you can skip this step.)
Using Oracle Applications Manager, update the following context variables:
s_afjsmarg = -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 or -Dhttps.protocols=TLSv1.2. The choice of setting here will depend on the protocol set in Section 5.3, Step 1 or Section 6.1.3.
s_proxyhost = fully qualified host.domain name
s_proxyport = port value
s_proxybypassdomain = domain name (Example hostname.example.com)
s_nonproxyhosts = wildcard domain name (Example *.example.com)
Run AutoConfig using the adautocfg.sh script in the application tier $ADMIN_SCRIPTS_HOME directory.
Use the adstpall.sh/adstrtal.sh script in the $ADMIN_SCRIPTS_HOME directory to stop and restart all services.

7.4 Separate Certificates for Inbound and Outbound Communication

In the case where you do not wish to use the external CA certificate for outbound connections, you can opt to use separate certificates for inbound and outbound communication. Use external CA certificates for inbound (and loopback) connections to the externally visible web entry point and use private CA certificates for the internal communications. Examples of this type of communication are:

Proxy -> OHS
OHS -> WLS
WLS -> DB
Applications tier -> DB

In this scenario the external CA certificate needs to be configured on the web entry point and all https clients (external and Oracle E-Business Suite loopback) must trust the rootCA certificate from that external CA. One would only need certificates for the outbound connections if the remote server requires a client certificate (i.e. Mutual Authentication). This could happen for some XML Gateway use cases.

In order to configure the internal entry points with the certificates from a private CA, all the internal https clients (App tier Java and DB) must be configured to trust the rootCA certificate from that private CA.

Certificate Usage

Communication	Connection Type	Certificate Type	Instruction
EBS to OHS or EBS to Proxy	Inbound or loopback	For inbound or loopback, external CA certificates are used.	For inbound or loopback, follow the general TLS implementation documented in this note.
Outbound	For outbound, a separate certificate can be used, issued by a public CA, or in-house/self-signed certificates can be used.	For outbound, the rootCA of the separate certificate must be added to the truststore when acting as a client. For the client authentication, you only need the certificate for the outbound connection.
Proxy to OHS OHS to WLS WLS to DB Apptier to DB WLS admin port to WLS OPMN to OHS	Proxy to OHS, Appstier to DB, and OHS to WLS WLS to DB	In-house or self-signed certificates can be used.	Proxy to OHS is covered in the end-to-end TLS steps in this note. Application tier to database and OHS to WLS are also covered in this note. Be certain to add the rootCA to the truststore wherever the note mentions to update the truststore. WLS to DB only supports non-PKI encryption so far.

Communication

Connection Type

Certificate Type

Instruction

EBS to OHS or EBS to Proxy

Inbound or loopback

For inbound or loopback, external CA certificates are used.

For inbound or loopback, follow the general TLS implementation documented in this note.

Outbound

For outbound, a separate certificate can be used, issued by a public CA, or in-house/self-signed certificates can be used.

For outbound, the rootCA of the separate certificate must be added to the truststore when acting as a client. For the client authentication, you only need the certificate for the outbound connection.

Proxy to OHS
OHS to WLS
WLS to DB
Apptier to DB
WLS admin port to WLS
OPMN to OHS

Proxy to OHS, Appstier to DB, and OHS to WLS

WLS to DB

In-house or self-signed certificates can be used.

Proxy to OHS is covered in the end-to-end TLS steps in this note. Application tier to database and OHS to WLS are also covered in this note. Be certain to add the rootCA to the truststore wherever the note mentions to update the truststore.

WLS to DB only supports non-PKI encryption so far.

Section 8: Renew Expired Certificates

This section covers the case where you have an existing SSL/TLS instance and only need to renew your certificate. The certificate request remains unchanged, and depending on the Certifying Authority that issued the certificate, will only require the original certificate request to renew the certificate.

Back up the existing wallet and any associated files in your wallet directory.
Copy over your newly issued certificate and save it as server.crt.
If you were also provided updated root and intermediate certificates, copy these over as well to your wallet directory.
Start the Oracle Wallet Manager.
Open your existing wallet.
Highlight 'Certificate: [Ready]'
Right-click and select 'Remove User Certificate'.
Acknowledge 'Yes' for removal.
This changes the 'Certificate: [Requested]'
Import any new or updated root and intermediate certificates as 'Trusted Certificates'.
Import the new 'User Certificate' - server.crt
This changes 'Certificate: [Ready]' once again.
Save the updated wallet and exit Oracle Wallet Manager.

With the wallet now updated with the updated certificate, you will need to update the rest of the TLS setup by following 5.2 Configure Inbound Connections - Steps 6 through 8 to update the wallet information, as well as 5.3.1 Perform the General Required Configuration - Step 2 with the update to the b64InternetCertificate.txt file.

The steps in 5.3.2 Database Tier Setup would only be required if the root certificates were updated as part of your newly issued certificate. You only need to import the root certificates as 'Trusted Certificates' into the wallet used by the database.

You will also need to recreate the ewallet.jks with the updated certificate by following 5.4 Enable TLS for WLS AdminServer, Step 1 and 2.

Section 9: Alternate TLS Termination Point

This section covers alternative configurations for TLS.

9.1 Alternate TLS Termination Point Other than OHS
9.2 End-to-End TLS

9.1 Alternate TLS Termination Point Other than OHS

If you want to use a reverse proxy or load balancer as the only TLS termination point to off-load or handle the encryption and decryption of TLS inbound HTTP traffic:

Perform the Steps for Oracle E-Business Suite configuration instead of the steps described previously in this document.
Configure a reverse proxy or a load balancer by following the instructions from the vendor of your choice.
- If you choose to use HAProxy, follow Section 3 through 5 in Document 2012639.1, Using HAProxy as a TLS Termination Point for Oracle E-Business Suite Release 12.1.3. (The HAProxy instructions in this document are applicable for both Oracle E-Business Suite Release 12.1 and Release 12.2.)
- If you choose to use Oracle Traffic Director, follow Document 2130592.1, Oracle Traffic Director 12c Integration with Oracle E-Business Suite Releases 12.1 and 12.2.

Steps for Oracle E-Business Suite Configuration

Use the Oracle E-Business Suite 12.2 - Oracle Applications Manager (OAM) Context Editor to change the TLS-related variables shown in the following table.

Changes When Using a TLS Termination Point Other than OHS (Such as a Load Balancer or Reverse Proxy)

Variable	Non-TLS Value	TLS Value
`s_url_protocol`	http	http
`s_local_url_protocol`	http	http
`s_webentryurlprotocol`	http	https
`s_active_webport`	same as s_webport	TLS termination point external port
`s_webentryhost`	same as s_webhost	TLS termination point hostname
`s_webentrydomain`	same as s_domainname	TLS termination point domain name
`s_enable_sslterminator`	#	Remove the '#' to use ssl_terminator.conf
`s_login_page`	URL constructed with HTTP protocol and s_webport	Construct URL with HTTPS protocol, s_webentryhost, s_webentrydomain, s_active_webport
`s_external_url`	URL constructed with HTTP protocol and s_webport	Construct URL with HTTPS protocol, s_webentryhost, s_webentrydomain, s_active_webport

The value of the s_webport is based on the default port prior to any TLS configuration, and remains unchanged when switching to TLS.

Run AutoConfig using the adautocfg.sh script in the application tier $ADMIN_SCRIPTS_HOME directory.
Use the adstpall.sh/adstrtal.sh script in the $ADMIN_SCRIPTS_HOME directory to stop and restart all services.
Verify that https connectivity is working properly before propagating the changes from the run edition to the patch edition using adop phase=fs_clone.

9.2 End-to-End TLS

In this case, the TLS configuration for the inbound HTTP connections consists of TLS configured at the Oracle E-Business Suite/OHS level, in addition to use of a reverse proxy or load balancer. Use these steps once you have completed all steps in this note, including the steps for 'Alternate TLS Termination Point other than OHS' outlined below. The only difference being the changes as indicated in this section.

Perform all steps in this document as described.
For the configuration of a reverse proxy or a load balancer, follow the instructions from the applicable vendor.
- If you choose to use HAProxy, follow Section 3 through 5 in Document 2012639.1, Using HAProxy as a TLS Termination Point for Oracle E-Business Suite Release 12.1.3. (The HAProxy instructions in the document are applicable for both Oracle E-Business Suite Release 12.2 and Release 12.1.)
- If you choose to use Oracle Traffic Director, follow Document 2130592.1, Oracle Traffic Director 12c Integration with Oracle E-Business Suite Releases 12.1 and 12.2.

End-to-End TLS

In the event that you wish to make use of TLS on the Oracle E-Business Suite OHS side, in addition to TLS termination point configuration, you will want to be aware of the following settings:

Use the Oracle E-Business Suite 12.2 - Oracle Applications Manager (OAM) Context Editor to change the TLS related variables shown in the following table.

Changes When Using End-to-End TLS

Variable	TLS Value
`s_url_protocol`	https
`s_local_url_protocol`	https
`s_webentryurlprotocol`	https
`s_webssl_port`	TLS port of Oracle E-Business Suite
`s_https_listen_parameter`	TLS port of Oracle E-Business Suite
`s_active_webport`	TLS termination point external port
`s_webentryhost`	TLS termination point host name
`s_webentrydomain`	TLS termination point domain name
`s_enable_sslterminator`	Remove the '#' to use `ssl_terminator.conf`
`s_login_page`	Construct URL with https protocol, `s_webentryhost`, `s_webentrydomain`, `s_active_webport`
`s_external_url`	Construct URL with https protocol, `s_webentryhost`, `s_webentrydomain`, `s_active_webport`

Run AutoConfig using the adautocfg.sh script in the application tier $ADMIN_SCRIPTS_HOME directory.
Use the adstpall.sh/adstrtal.sh script in the $ADMIN_SCRIPTS_HOME directory to stop and restart all services.
Verify that https connectivity is working properly before propagating the changes from the run edition to the patch edition using adop phase=fs_clone.

We advise that both sides of the TLS configuration be tested independently. For example, test to make sure your Oracle E-Business Suite instance works with the TLS termination point first, revert the change, and then test that TLS terminated locally at the Oracle E-Business Suite/OHS level works. Once it is confirmed that both configurations work for TLS, you can commit to the end-to-end TLS configuration by re-introducing the TLS termination point.

An example of the protocol flow in this scenario:

client https request > TLS Off-loader (https:443) > Oracle E-Business Suite TLS (https:4443)

There are two distinct TLS certificate chains in play, therefore the TLS handshake and negotiation must complete in order for the communication to be successful. Any break in this flow will result in TLS protocol errors. In this example, the TLS termination point is operating on the general default port of 443, while Oracle E-Business Suite is configured to operate on port 4443.

Section 10: Reuse Certificates

In the case where Oracle E-Business Suite 12.2 was upgraded from a Release 12.1, 12.0, or an 11i instance, you can use (or reuse) your existing certificate as long as there is no change in the host name and the existing certificate is SHA-2.

The following information uses a Release 11i to Release 12.2 upgrade scenario as an example, although the same holds true for Release 12.1 and 12.0:

The OWM 10.2 wallet can be opened and saved in OWM/orapki from 11.1.1.9.
The mod_ssl certificate files (11i and 12.1.3 with mod_ssl) can be converted to a PKCS#12 file (ewallet.p12) using openssl, and can be either directly opened and saved in OWM/orapki from 11.1.1.9 with auto_login, or
the openssl generated .p12 file can be converted to a keystore and then back to a wallet.

Items required for using 11i certificates to create 12.2 wallet are as follows:

server.crt - Server certificate file
intermediate.crt or intca.crt - Intermediate authority certificate file (there may be more than one intermediate)
root.crt or ca.crt - Root authority certificate file
server.key - Private server key file generated at time of creating certificate signing request

Copy the certificate files into the new wallet location.
$ cp server.crt certfile $ cat root.crt intermediate.crt intca.crt > cacertfile $ cp server.key keyfile
Create wallet from the previously listed certificates and key.
$ openssl pkcs12 -export -in certfile -inkey keyfile -certfile cacertfile -out ewallet.p12
Convert wallet to keystore.
$ $FMW_HOME/oracle_common/bin/orapki wallet pkcs12_to_jks -wallet ./ewallet.p12 -jksKeyStoreLoc ./ewallet.jks -jksKeyStorepwd <PASSWORD>
Where <PASSWORD> corresponds to your wallet password.
Rename the previous p12 wallet generated previously in step 2.
$ mv ewallet.p12 ewallet.p12.bak
Create an empty 11g wallet.
$ $FMW_HOME/oracle_common/bin/orapki wallet create -wallet ./
Get the keystore from step 3 into empty wallet.
$ $FMW_HOME/oracle_common/bin/orapki wallet jks_to_pkcs12 -wallet ./ewallet.p12 -pwd <PASSWORD> -keystore ./ewallet.jks -jkspwd <PASSWORD>
Where the first <PASSWORD> corresponds to your wallet password, and the second <PASSWORD> corresponds to your keystore password.
Open the wallet in $FMW_HOME OWM, and verify that it shows in ready state, and check that auto-login is checked, save and close OWM.
$ $FMW_HOME/webtier/bin/owm
Display contents of wallet.
$ $FMW_HOME/oracle_common/bin/orapki wallet display -wallet ./ewallet.p12

Appendix A: Disable TLS

There may be a need to temporarily disable TLS for testing or for troubleshooting purposes. In such cases, use the following procedure to accomplish this, while at the same time not undermining the TLS configuration up to this point and allowing TLS to be enabled again. This would be done on the current run edition.

Revert the changes made to the respective .conf files per Step 9 - Update the Context File and Config Files of 5.2 Configure Inbound Connections.
In the case where Section 6.2 steps for disabling the HTTP port was implemented, undo the configuration changes under 6.2.2.
Run the adSyncContext.pl to sync up the changes (for standard TLS setup only).
Run AutoConfig.
Use the adstpall.sh/adstrtal.sh script in the $ADMIN_SCRIPTS_HOME directory to stop and restart all services.

In the event that the optional steps for 6.3 Enable TLS for WLS Managed Server were done, you will need to revert these steps as well.

Restore the backup of $EBS_DOMAIN_HOME/config/config.xml file.
Change Keystore setting to "Demo Identity and Demo Trust" which will clear all the "Custom Identity and Custom Trust" changes.
Enabled non-SSL Port and disable SSL Listen Port for all Managed servers.
For the Hostname Verification drop down, select either the "Custom Hostname Verifier" or "None"..
Roll back "Secure Replication Enabled" from clusters of oacore, forms, and oafm.
Sync up changes to the context file.
Remove SSL ports from context file.
$ perl $FND_TOP/patch/115/bin/txkSetAppsConf.pl \ -contextfile=$CONTEXT_FILE \ -configoption=removeMS \ -oacore=<host>.<domain>:<port> \ -oafm=<host>.<domain>:<port> \ -forms=<host>.<domain>:<port>
Add non-SSL ports to context file.
$ perl $FND_TOP/patch/115/bin/txkSetAppsConf.pl \ -contextfile=$CONTEXT_FILE \ -configoption=addMS \ -oacore=<host>.<domain>:<port> \ -oafm=<host>.<domain>:<port> \ -forms=<host>.<domain>:<port>
Modify the mod_wl_ohs.conf file and comment the below parameters, which were uncommented as part of the TLS configuration.
- #SecureProxy ON
- #WLProxySSL ON
- #WLSSLWallet "${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/keystores/default"
Run AutoConfig using the adautocfg.sh script.
Restart everything including the Admin and Managed Servers using the adstpall.sh and adstrtal.sh scripts. Ensure that everything started up successfully.
Run adop phase=fs_clone to sync up the run and patch file system.

Appendix B: References

Refer to the following sources for more information:

Oracle E-Business Suite Security Guide - Secure Configuration
Document 2063486.1, FAQ: Oracle E-Business Suite Security
Document 2143101.1, Enabling SSL or TLS in Oracle E-Business Suite Release 12.2
Document 1530033.1, Using the Latest JDK 7.0 Update with Oracle E-Business Suite Release 12.2
Document 2153042.1, Critical Patch Update July 2016 Patch Availability Document for Oracle Java SE
Document 1590356.1, Upgrading Oracle Fusion Middleware WebTier of Oracle E-Business Suite Release 12.2 to the latest 11gR1 (11.1.1.x) PatchSet
Document 1937646.1, CVE-2014-3566 - Instructions to Mitigate the SSLv3 Vulnerability ("POODLE Attack") in Oracle E-Business Suite
Document 1617461.1, Applying the Latest AD and TXK Release Update Packs to Oracle E-Business Suite Release 12.2
Document 1937220.1, Punchout in Oracle iProcurement and Exchange Fails After Supplier Site Migrates From SSLv3 to TLS Protocol (with SSL Handshake SSLIOClosedOverrideGoodbyeKiss)
Document 1448161.1, How To Produce CSR With A SHA-1 Or Better Signature Algorithm
Document 1275428.1, Support Status for SHA2 in Oracle WebLogic Server, Fusion Middleware 11g/12c and Oracle Application Server 10g
Document 1939223.1, How to Generate SHA2 Certificate Signing Requests WITHOUT Oracle Wallet Manager for FMW 11g Wallets
Document 1905593.1, Managing Configuration of Oracle HTTP Server and Web Application Services in Oracle E-Business Suite Release 12.2
Document 1926201.1, Interoperability Notes Oracle E-Business Suite Release 12.2 with Oracle Database 12c Release 1 (12.1.0)
Document 2038186.1, DMZ and SSL Configuration Guide for Oracle E-Business Suite Information Discovery, Release 12.2 V6
Document 2012639.1, Using HAProxy as a TLS Termination Point for Oracle E-Business Suite Release 12.1.3
Document 2130592.1, Oracle Traffic Director 12c Integration with Oracle E-Business Suite Releases 12.1 and 12.2
Document 2142774.1, FMW Patch 22288381: This Patch is Obsolete. It cannot be Downloaded
Document 1623879.1, Interoperability Notes Oracle E-Business Suite Release 12.2 with Database 11g Release 2 (11.2.0.4)
Document 1147107.1, Database Patch Set Update Overlay Patches Required for Use with PSUs and Oracle E-Business Suite
Document 2274242.1, TLS Protocol Options Available with Oracle Database 11.2.0.4 (MES Bundle patches)
Document 2484000.1, Identifying the Latest Critical Patch Update for Oracle E-Business Suite Release 12

Appendix C: Known Issues

Product	Component	Bug	Title / Comments
Oracle Applications Manager	Application Logging Interfaces	Bug 23245189	TECHP: ALL LOG VIEWING IN OAM FAILED WITH TLS1.2 PROTOCOL ON AIX This is an AIX-specific issue and is addressed by adding the following server startup argument as well, for oacore managed server: `-DUseSunHttpHandler=true`
Enterprise Manager Base Platform	System Monitoring	Bug 23271615	TECHP: Unable to config OHS in EM console if SSL version is TLS 1.2 in `opmn.xml` This issue is fixed by Patch 26045188.
Oracle HTTP Server	OHS Config MBeans	Bug 23630525	TECHP: HANDSHAKE FAILED WHEN NONJ2EEMANAGEMENT CONNECTS TO OHS ADMIN VIA TLS 1.2 This issue is fixed by Patch 23630525.
Workflow	Notifications	Bug 23605402	WHEN ONLY TLS V1.2 IS ENABLED SMALL WHITE BOXES APPEAR IN OA FRAMEWORK MAIL Requires minimum versions of JRE 1.6.0_141 or JRE 1.7.0_131 in order to address this issue.
OPMN	opmn.xml	Bug 24456131	This issue is fixed by Patch 24456131 which has been included in TXK delta 9 Patch 25180736.
Oracle iStore	Orders	Bug 22922211	This issue affects Windows customers only, after enabling TLS, users will face error and won't be able to place order from iStore using credit card.
Application Object Library	Help	Bug 21969510	This issue affects the iHelp functionality when opting to implement the steps in Section 6.2 Disabling the HTTP Port. This has also been noted within the same section along with a workaround.
OPMN	Startup	Bug 26105442	Use of large certificates causes startup failure for opmn. This has been addressed and fixed as a one-off Patch 21656630 applied on top of Oracle Fusion Middleware 11.1.1.9.
Application Object Library	Help	Bug 27648939	This issue affects the iHelp functionality when opting to implement the steps in Section 6.2 Disabling the HTTP Port while making use of in-house or self-signed certificates. Until this is resolved, customers with these type of certificates should not disable the HTTP port.
Oracle Applications Manager	Clone	Bug 28765108	If you perform the steps in Section 5.4 and then clone the instance, the WLS admin server might fail to start in the target instance. Development is working on a fix.
Enterprise Manager Base Platform	System Monitoring	Bug 26493558	For ECC certificate usage only, customer will not be able to edit OHS configuration file via the Fusion Middleware control console. Customer can use a command line editor to modify the OHS configuration file.
Oracle Security Service	Wallet	Bug 23277842	Customers on database 11.2.0.4 and ECC certificates - orapki command does not support use of the "-jsafe" parameter.
Oracle WebLogic Server	WLS Security	Bug 29154949	This issue affects Windows customers only, after enabling TLS for the WLS managed server, forms functionality will not work. Currently awaiting outcome of bug 30121289.
Oracle WebLogic Server	WLS Security	Bug 28934164	Upon stopping WLS Admin Server, security messages are displayed. These can be ignored, as there is no functional impact. These will be addressed with future JDK certification. The messages start with BEA-090905/BEA-090906/BEA-090908 messages, followed by a number of BEA-090898 entries related to certificates.

Change Log

Date	Description
2021-01-13	Updated Section 5.1 - Added information with respect to patching, and that these steps can be performed either proactively as part of an active patching cycle, or applied to the run edition. Added Known Issue for bug 28934164. Added orapki command in Section 5.2, Step 3 to create generic self-signed certificate request. Added reference to Oracle Database 19c in Section 5.3.2. Made various minor typographical and grammatical updates throughout doc.
2020-05-12	Updated Section 6.5.
2020-03-13	Updated Section 4.2 Removed the "for the connection encryption" reference from the end of each of the examples. Removed reference to having to include the intermediate certificate for in-house certificates within the client side Java keystore. Updated Section 5.3.1, Step 1 Removed reference to Wild Card and SAN certificates. Added required parameter -> `-DUseSunHttpHandler=true` Modified Note box with the `-Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2` parameter as required based on JDK patch level. Updated Section 6.1.3 with Note box that this step is only needed if you are not already on April 2017 JDK or later. Added Section 6.5 Configuration for Forward Secrecy Added Known Issue for bug 29154949. Updated Section 6.2 to address use of privileged port.
2019-04-25	Updated Section 5.2, Step 8 relative to wallets so that the same wallet is used at each location. This goes to EM console related functionality.
2019-04-19	Updated Section 5.1, Step 4 with additional information pertaining to Oracle Payments.
2019-01-08	Updated Section 5.2, Step 8 relative to wallets. Added Section 5.1.1 for 11.2.0.4 DB and ECC certificates. Updated Section 6.1.1 Note block for 11.2.0.4 DB. Added Known Issue for bug 23277842. Updated Section 5.1, Step 1 for JDK requirements and removed references to JDK6 leaving JDK7 as the required minimum going forward.
2018-11-06	Added Known Issue for bug 26493558, and also mentioned it in Section 5.2 Step 9, Sections 6.2.2, and 6.4. Updated Section 5.2, Step 8 for ECC certificates.
2018-10-19	Updated optional TLS setup for AdminServer and managed servers and made the AdminServer a required configuration under new section 5.4. Modified existing section 6.3 to reference only the optional TLS configuration for the managed servers. Updated section 5.3.1 and added the need to set the Custom Hostname Verifier to weblogic.security.utils.SSLWLSWildcardHostnameVerifier when using SAN or Wild Card certificates. Added note under Section 6.2 for disabling HTTP port when using in-house or self-signed certificates. Also added this to Known Issues. Updated Section 5.2, Step 8 for the wallet files. Updated Discoverer guidance in Section 7.1 Added information on JWS to Section 4. Added Section 6.4 for HSTS. Added Known Issue for bug 28765108.
2018-07-03	Added information to Section 3 for SAN and Wild Card certificates. Updated Section 5.2, Step 3 to add reference to SAN and Wild Card certificate usage. Added information on in-house and/or self-signed certificates under Section 3. Added JDK minimum requirements under Section 5.1, Step 1. Added JRE minimum requirements under Section 6.1.1. Added Section 7.4 for information on use of separate certificates for inbound and outbound communication. Added Known Issue for bug 26105442 for large certificates. Doc bug 28125088 - Updated Section 6.1.1 for support of Oracle Database 11.2.0.4 and TLS 1.2. Updated Section 5.3.1, Step 1 and added a step for Wild Card/SAN certificate usage.
2018-02-02	Added information on PKI to Section 3. Updated Section 8 with additional information on renewing certificates. Updated Section 5.1, Step 5 and changed the reference from patch 23630525 to patch 26045188 for the redeployment. Added Known Issue under Section 6.2 and also in the Known Issues section for bug 21969510 and iHelp. Added Section 10 for information on reusing existing certificates per doc bug 21427521. Removed the Known Issue pointing to bug 24441250 as this is the same issue as Known Issue added for bug 21969510.
2017-12-15	Added information for ECC to the following sections: Section 5.1, Step 2 Section 5.2, Step 2 Section 5.2, Step 7 Section 5.3.1, Step 3 Section 5.3.2 Section 6.3.2, Step 2 Added Section 9: Alternate TLS Termination Point and moved previous information into this section for clarity. This separates the base level TLS configuration from the alternate configurations of using either TLS off-loading/acceleration, and end-to-end TLS. Updated Known Issues for doc bug 27079410. Updated Step 6.2.1 to clarify correct patch to download and apply.
2017-06-28	Updated Section 6.3 to reference the use of 'Custom Identity and Custom Trust' only, as use of 'Custom Identity and Java Standard Trust' is currently not supported.
2017-06-02	Updated SSLCipherSuite to exclude 3DES.
2017-05-23	Added Note box to the end of Section 5 on adop usage involving privileged ports. This was based on Customer/Support feedback.
2017-05-17	Updated FMW 11.1.1.9 patch requirements in Section 5.1, Step 5 - removed patch 25072950 and replaced it with patch 23630525 and 26045188. The patch 26045188 is a merge of 25072950 and 25955458. Updated Section 6.1.2 and set the SSLProtocol to nzos_Version_1_2 only and removed the note about the known issue for bug 23630525. Updated Known Issues section to reflect these same changes noted here.
2017-05-12	Added Section 7.3 for Service Invocation Framework - SOA functionality. Updated Section 6.3 for optional configuration of WLS admin and managed servers. Updated Section 5.1, Step 5 for post patch 25072950 steps. Updated Appendix A: Disabling TLS. Updated list of linked document references.
2016-12-09	Updated Section 5.1 to include patch 25072950. Updated Section 5.2, Step 7 and Section 6.1.2 for fix provide by patch 25072950.
2016-12-02	Added information in Section 5.1 for patch 24456131 which fixes previous Known Issue, and also removed note entry under 5.3.2 for the same. Added Known Issue for WLS and SSL enabling, which is currently not supported, but will be soon. Information on this will be added under Section 6.3 once available.
2016-10-20	Updated Section 5.3.1 and 6.1.3 to separate the steps for adding the JVM parameter for the managed servers and the admin server.
2016-10-04	Updated Section 6.2.1 Required Patches and removed references to FMW 11.1.1.7 patching requirements, as TLS 1.2 usage requires FMW 11.1.1.9 Instructions for Encrypting Database Network Traffic Using ANO/ASO (Optional) are currently available in My Oracle Support Knowledge Document 2143101.1 Enabling SSL or TLS in Oracle E-Business Suite Release 12.2. Given that ANO/ASO is not related to TLS encryption, we are currently planning to add this section to the Security Administration Guide. This change log will be updated when this is complete.
2016-09-14	Updates to Section 5.1 related to JDK
2016-09-02	Updated information for Discoverer in Section 7.1
2016-08-16	Added information on fs_clone to the end of Section 5 Added Known Issue for opmn.xml and fs_clone and bug 24456131 Added Known Issue for Help for and 24441250
2016-08-03	Added Note box to 5.2 Step 8 to take into account shared file system and multinode Removed line about Workflow from the Attention box in 6.1 Added Known Issue on bug 23605402
2016-07-28	Moved bug 23630525 information from 5.2 step 7 to 6.1.2
2016-07-25	Corrected minor typo in Section 2 Updated image in Section 4
2016-07-21	Various content updates and structure changes throughout document Updated 5.1 - Removed "Apply Patch 19849290 to FMW 11.1.1.7." since FMW 11.1.1.9 is required for TLS 1.2 backward compatibility
2016-06-27	Corrected MOS syntax for image display in Section 4
2016-06-22	Initial publication of new content. Previous content can be found in My Oracle Support Knowledge Document 2143101.1

My Oracle Support Knowledge Document 1367293.1 by Oracle E-Business Suite Development.

Tuesday, June 22, 2021

Enabling TLS in Oracle E-Business Suite Release 12.2 (Doc ID 1367293.1)