Document 376700.1 PDF

Document 376700.
1 de 26
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-stat...
Enabling SSL or TLS in Oracle E-Business Suite Release 12 (Doc ID 376700.1)
Enabling SSL or TLS in Oracle E-Business Suite Release 12

In This Document
Section 1: Introduction
Section 2: Concepts and Terminology
Section 3: Application Tier Setup
Section 4: Database Tier Setup
Section 5: Advanced SSL Setup
Section 6: Converting Existing Certificates
Section 7: Creating your Certifying Authority's Certificate
Section 8: Oracle Application Server Certificate Authority
Section 9: Disabling Older SSL Protocols and Weak Ciphers
Section 10: Encrypting Database Network Traffic using ANO/ASO
Section 11: Renewing Revoked or Expired Certificates
Appendix A - Using Network Traffic Encryption
Appendix B - Disabling SSL
This document explains the setup steps for enabling SSL in Oracle E-Business Suite Release 12.0 and 12.1; for Release 12.2, use document
1367293.1 instead.
The most current version of this document can be obtained in My Oracle Support Knowledge Document 376700.1.
There is a change log at the end of this document.
Section 1: Introduction
The most significant change for Secure Sockets Layer (SSL) support in Oracle E-Business Suite Release 12 is the use of the mod_ossl
module for the Oracle HTTP Server. Like mod_ssl, the mod_ossl plug-in enables strong cryptography for Oracle HTTP Server. In contrast to
the OpenSSL module, mod_ossl is based on the Oracle implementation of SSL, which supports SSL and TLS protocols, and is based on
Certicom and RSA Security technology.
In Oracle E-Business Suite Release 12 SSL certificates will be managed by Oracle Wallet Manager 10g, which will be accessible via the
familiar OWM graphical user interface (GUI) or the new ORAPKI command line interface (CLI). Since Oracle E-Business Suite Release 12
uses the Forms Listener Servlet, a separate certificate is no longer needed for Forms as it will share the same wallet as the Oracle HTTP
Server.
In keeping with the theme of security, and as part of implementing SSL, it is recommended that you also review your current JRE
deployment, as well as looking into enhanced JAR file signing. Refer to document 393931.1 for information on obtaining the most current
JRE, and document 1591073.1 for information on signing JAR files.
Note: Use of the Forms Server Listener with ConnectMode=https is not supported. ConnectMode=https only works with JInitiator,
which includes the Oracle SSL libraries. Release 12 uses the Sun Java Plugin. If you need to use https for the Forms communication
layer you must use the servlet architecture.
Section 2: Concepts and Terminology

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).
Transport Layer Security (TLS)
Transport Layer Security is a cryptographic protocol that ensures privacy between communicating applications and their users on the
Internet. While SSL is supported with all versions of the Oracle Application Server, TLS requires a minimum of Application Server 10.1.2.0.
Oracle Applications Release 12 supports the use of both SSL and TLS.
SSL uses 2 types of certificates:
3/07/2016 12:52 p. m.
Document 376700.1
2 de 26
User certificates - issued to servers or users to prove their identity in a public key/private key exchange.
Trusted certificates - representing entities who you trust, such as certificate authorities.
How SSL works with Application Tier Oracle HTTP Server:

1. The client sends a request to the server using HTTPS connection mode.
2. The server presents its certificate to the client. This certificate contains the server's identifying information.
3. The client checks its list of trust points and compares the information in the certificate with the server's public key. If it matches, the
server is authenticated as a trusted server.
4. The client sends the server a list of the encryption levels, or ciphers, that it can use.
5. The server receives the list and selects the strongest level of encryption that they have in common.
6. The client creates a session key which is used to encrypt the data, and sends this session key to the server which can decrypt the
data with its private key
How SSL works with Oracle Database Server:

1. The UTL_HTTP package is used for making HTTP callouts from SQL and PL/SQL to a Web Node (Oracle HTTP server).
2. When the package fetches data from a Web site using HTTPS, it specifies the location to the Oracle Wallet that resides on the
database server. This wallet contains the certificate for the Certifying Authority (CA) that signed the Web node's server certificate.
Certificate Authority (CA)

A Certificate 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 Certifying 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 Certification 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 your organization)
3. Digital signature of the trusted CA private key
Verisign (http://verisign.com/) will allow your organization to apply for a free trial certificate which will be valid for 2 weeks for testing
purposes.
Private (Server) Key

The private key file is a digital file that you generate and for use to decrypt messages sent to you. 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.
Global Server Certificates

Global Server Certificates, also referred to as Server Gated Cryptography, are 128 bit certificates that enable all browsers to use 128 bit
encryption, even if the browser only supports 40 bit encryption. A global server certificate usually has 2 parts: the certificate itself and an
extra intermediate certificate which is used to provide the step-up. The marketing names of these certificates vary depending on the
company that issues the certificate, for example, Thawte calls them 128 bit SuperCerts. It is not possible to get trial versions of global server
certificates; therefore it is not possible to test unless one is purchased.
Secure Socket Layer Accelerators

Secure Socket Layer (SSL) Accelerators can be used to reduce the SSL traffic and workload off the web servers. Usually SSL accelerators are
the primary targets for https requests from the user's desktop and thus are the initial target for all desktop client communication. They are
responsible for converting "https" SSL requests to non-SSL "http" requests, directing the request to the http server which is running in
non-SSL mode. Before sending the response back to the desktop they again convert the non-SSL response to SSL response.
If you are planning on using an SSL Accelerator only, you can skip steps 1 through 7 in Section 3, and proceed to Step 8, referencing the
3/07/2016 12:52 p. m.
Document 376700.1
3 de 26
table - Changes when using an SSL Accelerator. Please make certain that the SSL certificate used on the SSL Accelerator is in place.
Consult the documentation for your SSL Accelerator as needed. If you are also enabling SSL at the Oracle E-Business Suite level in addition
to the SSL Accelerator, then all steps in Section 3 would still apply.
If you are making use of a self-signed, in-house, or trial certificate and the root CA or any intermediate certificate component is not found in
the certificate chain, errors may be encountered. In this case, you would need to follow all the steps in Section 3, starting with step 5. In
addition, you may also need to import the root CA into the client side JRE trust store.
Windows -> Control Panel -> Programs -> Java -> Security (tab) -> Manage Certificates
From here you can import Trusted Certificates as well as Signer CA certificates. Depending on the type of certificate, you may also need to
import the same certificate components into the client side browser.
Note: If you plan to use "cookie based session persistence" at the HTTP Load Balancer level, and you plan to enable SSL for HTTP
traffic at all application tier Web Nodes, you have to use a SSL Accelerator as the Web Entry Point Host. This is because HTTP Load
Balancers cannot intercept the SSL encrypted communication between the Client Browser and the application tier Web Server to insert
or delete cookies to maintain session persistence. It is advantageous to use SSL accelerators because it requires less maintenance as
none of the application tier Web Nodes have to be configured for SSL.
Inbound Encryption
This involves connections from a client to the Oracle HTTP Server (OHS) delivered with the Oracle E-Business Suite applications Technology
stack. With inbound connections, the SHA (can be SHA-1 or 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 via the network using a browser.
- User accesses Oracle E-Business Suite application via 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 communicates with the E-Business Suite via a REST service.
Outbound Encryption
This involves connections from Oracle E-Business Suite to external site(s). For outbound connections, the SHA (can be SHA-1 or 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.
Example include, but are not limited to the following:
- Punchout in 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
Loopback Connection
This involves connections from Oracle E-Business Suite back to the Oracle HTTP Server (OHS) delivered with the Oracle E-Business Suite
applications technology stack. For loopback connections, the SHA (can be SHA-1 or 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:
- Workflow notification emails from the Concurrent Manager tier.
- Payments call back from the Database tier.
- Oracle Process Manager (OPMN).
- Oracle Applications Manager Log Viewer.
Section 3: Application Tier Setup

The default location for the wallet in Oracle E-Business Suite Release 12 is $INST_TOP/certs/Apache. This directory contains a wallet with
demo certificates. If you wish to use these certificates for testing start with Step 8 below to configure SSL, and then perform Steps 1
through 7 when you are ready to switch to real certificates. The demo certificates are not secure and should never be used in a production
environment.
If you are using clients (JRE 8, some modern browsers) or Oracle Database 12c, you must perform the following:
- Upgrade FMW 10.1.3 to 10.1.3.5 as per Document 454811.1.
3/07/2016 12:52 p. m.
Document 376700.1
4 de 26
- Apply the October 2015 CPU (Patch 21845960).

Refer to Section 4: Database Tier Setup for testing the Oracle Database Tier
Note: SHA-2 signed PKI certificates are now certified with the Oracle HTTP Server for Oracle E-Business Suite 12.1.3. You must apply
the minimum requirements when using SHA-2 signed PKI certificates. Minimum requirements include the following:
- Apply at least the October 2015 CPU to FMW 10.1.3.5 as per Document 2051000.1. Oracle E-Business Suite always recommends you
apply the latest CPU.
- For AIX and HP Itanium only, also apply patch 21948197 to FMW 10.1.3.5.
- For Windows only, also apply patch 22251660 to FMW 10.1.3.5.
- OpenSSL version 0.9.8za or higher.
If you are enabling SSL/TLS for the first time, follow steps in Section 3. If you are updating to a SHA-2 signed PKI certificate, perform
the steps listed in Section 11.
For HP Itanium and Windows only, reference the steps noted for the mkwallet command, as opposed to the Oracle Wallet Manager,
as these are required for these platforms.
Testing is performed with all CPU patches applied across the technology stack components and the Oracle E-Business Suite. You can
apply the October 2015 CPU (Patch 21845960) to FMW 10.1.3.5 without applying the October 2015 CPU to all components; however,
we recommend that customers apply the latest CPU across all technology stack components and the Oracle E-Business Suite.
The main steps for setting up SSL on the Application Tier are:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Set Your Environment.

Create a wallet.
Create a Certificate Request.
Submit the Certificate Request to a Certifying Authority.
Import your Server Certificate to the Wallet.
Copy the Apache Wallet to the OPMN Wallet.
Update the JDK Cacerts File.
Update the Context File.
Run Autoconfig.
Restart the application tier services.
These instructions involve the use of the Oracle Wallet Manager Graphical User Interface. If you would prefer to use the Oracle Wallet
Manager Command Line Interface refer to My Oracle Support Knowledge Document 376694.1: Using the Oracle Wallet Manager Command
Line Interface in Release 12.
If you have unexpired certificates from your Oracle E-Business Suite Release 11i SSL instance you can convert them using the instructions in
Section 6 .
Note: Discoverer users who enable SSL for the E-Business Suite must also enable SSL for Discoverer.
Please refer to the following documents:
- Oracle Application Server Business Intelligence documentation
- For Discoverer without Portal or Single SignOn (SSO) refer to My Oracle Support Knowledge Document 338071.1 - How To Configure
Discoverer 10g (10.1.2) Plus/Viewer For HTTPS (SSL) Access
- For Discoverer with Portal and/or Single SignOn (SSO) refer to My Oracle Support Knowledge Document 339448.1 - Quick Start to
Configure Discoverer Plus/Viewer/Portlet Provider 10.1.2.0.2 in SSL + SSO
Step 1 - Set Your Environment

1. Logon to the application tier as the OS user who owns the application tier files.
2. Source your application tier environment file (APPS<sid_machine>.env) located in the APPL_TOP directory.
3. Navigate to the $INST_TOP/ora/10.1.3 and source the <sid_machine>.env file to set your 10.1.3 ORACLE_HOME variables.
3/07/2016 12:52 p. m.
Document 376700.1
5 de 26
Note: When working with wallets and certificates you must use the 10.1.3 executables.
Step 2 - Create a wallet

Using the Oracle Wallet Manager:
1. Navigate to the $INST_TOP/certs/Apache directory.
2. Move the existing wallet files to a backup directory in case you wish to use them again in the future.
3. Open the Wallet manager as a background process:
$ owm &
4. On the Oracle Wallet Manager Menu navigate to Wallet -> 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 YES when prompted:
A new empty wallet has been created. Do you wish to create a certificate request at this time?
Using the mkwallet command:
1. Proceed to Step 3 - Create a Certificate Request. The use of mkwallet creates the wallet and also generates the certificate
request.
Step 3 - Create a Certificate Request

After clicking "Yes" in step 2 the Create Certificate Request Screen will pop up:
Fill in the appropriate values where:

Common Name: is the name of your server including the domain.
Organizational Unit: (optional) The unit within your organization.
.
Organization: is the name of your organization.
Locality/City: is your locality or city.
State/Province: is the full name of your State or Province - do not abbreviate.
Select your Country from the drop down list, and for the Key Size, select 2048 as a minimum. Click OK.
Note: Depending on your certificate provider, they may not accept the MD5 based certificate request (CSR) generated by
the Oracle Wallet Manager (OWM). For example, VeriSign will now only accept SHA-1 2048 bit based CSRs or higher. In
3/07/2016 12:52 p. m.
Document 376700.1
6 de 26
such cases, you will need to create a CSR signed with a SHA based signature algorithm using another tool. Refer to
Section 9 and Signature Algorithm Changes.
Note: When importing or adding SHA-2 signed PKI certificates, mkwallet (not Wallet Manager) is required for HP Itanium and Windows.
1. Execute the mkwallet command
mkwallet -r <wallet password> . "CN=<Your host name of your server including the domain>, OU=<The unit
within your organization>, O=<name of your organization>, L=<your locality or city>, ST=<the full name of
your State or Province - do not abbreviate>, C=<country>" 2048 server-md5.csr
For example:
mkwallet -r <wallet password> . "CN=ebs.example.com, OU=TLS, O=Example Inc, ST=California, C=US" 2048
server-md5.csr
Note: Depending on your certificate provider, they may not accept the MD5 based certificate request (CSR) generated by the Oracle
Wallet Manager (OWM). For example, VeriSign will now only accept SHA-1 2048 bit based CSRs or higher. In such cases, you will need
to create a CSR signed with a SHA based signature algorithm using another tool. Refer to Section 9 and Signature Algorithm Changes.
Step 4 - Submit the Certificate Request to a Certifying Authority

You will need to export the Certificate Request before you can submit it to a Certifying Authority.
1.
2.
3.
4.
5.
6.
7.
Click on Certificate [Requested] to Highlight it.

From the menu click Operations -> Export Certificate Request
Save the file as server.csr
From the menu click Wallet and then click Save.
On the Select Directory screen change the Directory to your fully qualified wallet directory.
Click OK.
From the menu click Wallet and check the Auto Login box.
Be sure to make this 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 a uto login enabled processes
submitted by the OS user who created the wallet will not need to supply the password to access the wallet.
8. Exit the Wallet Manager.
The wallet directory will now contain the following files:
cwallet.sso
ewallet.p12
server.csr
You may now submit server.csr to your Certifying Authority to request a Server Certificate.
1. Submit the CSR generated from Step 3 - Create a Certificate Request to your Certifying Authority to obtain your server certificate
along with any additional trusted certificates that may be required.
Step 5 - Import your Server Certificate to the Wallet

3/07/2016 12:52 p. m.
Document 376700.1
7 de 26
After you receive your Server Certificate from your Certifying Authority you will need to import it into your wallet. Copy the
certificate to server.crt in the wallet directory on your server by one of the following methods:
Note: If all trusted certificates that make up the chain of server.crt are not present in the wallet, then adding the
certificate will fail. When the wallet was created, the certificates for the most common CAs (such as VeriSign, GTE, and
Entrust) were included automatically. Contact your certifying authority if you need to add their certificate, and save the
provided file as ca.crt in the wallet directory in a base64 format. Another option is to follow the instructions in Section 7 to
create ca.crt from your server certificate (server.crt). If your Certifying Authority provided an intermediate certificate (to
complete the chain) then save the provided file as intca.crt in a Base64 format, this will need to be imported into Oracle
Wallet Manager prior to importing the server.crt. Certificates that comprise several parts (such as the P7B type) would also
fall into this category.
1. Copy the certificate (in binary mode)
2. copy and paste the contents into server.crt
Follow these steps to import server.crt into your wallet:
1. Open the Wallet Manager as a background process:
$ owm &
2. From the menu click Wallet then Open.

3. Answer Yes when prompted:
Your default wallet directory does not exist.
Do you want to continue?
4. On the Select Directory screen change the Directory to your fully qualified wallet directory and click OK
5. Enter your wallet password and click OK.
6. On the Oracle Wallet Manager Menu navigate to Operations - Import User Certificate.
Server certificates are a type of user certificate. Since the Certifying Authority issued a certificate for the server, placing
its distinguished name (DN) in the Subject field, the server is the certificate owner, thus the "user" for this user
certificate.
7. Click OK.
8. Double Click on server.crt to import it.
9. Save the wallet:
1. On the Oracle Wallet Manager Menu click Wallet.
2. Verify the Auto Login box is checked.
3. Click Save
If you need to import the CA Certificate you will also need to add the contents of ca.crt file to 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 you were also provided an Intermediate Certificate (intca.crt) then you will also need to add that to the
b64InternetCertificate.txt:
$ cat intca.crt >> <10.1.2 ORACLE_HOME>/sysman/config/b64InternetCertificate.txt

1. Import the received certificates into the wallet:
mkwallet -i <wallet password> .
ca.crt
mkwallet -i <wallet password> . intca.crt
mkwallet -i <wallet password> . server.crt
NZDST_CLEAR_PTP
NZDST_CLEAR_PTP
NZDST_CERTIFICATE
## root CA cert
## intermediate CA cert
## server cert
2. Verify the wallet contents:

mkwallet -p <wallet password> .
3. Enable Auto_login for the wallet:
3/07/2016 12:52 p. m.
Document 376700.1
8 de 26
mkwallet -s <wallet password> .
## This will create cwallet.sso
4. Import the root CA certificate as well as the intermediate CA certificate (if applicable) into b64InternetCertificate.txt:
cat ca.crt >> <10.1.2 ORACLE_HOME>/sysman/config/b64InternetCertificate.txt
cat intca.crt >> <10.1.2 ORACLE_HOME>/sysman/config/b64InternetCertificate.txt
Step 6 - Modify the OPMN wallet

The E-Business Suite Rapid Install process creates a default "demo" opmn wallet in the $INST_TOP/certs/opmn directory that can be used in
test instances for basic SSL testing. Now that the Apache wallet has been created you will need to to use these same certificates for opmn.
Use the following steps to backup and copy the wallets:
1.
2.
3.
4.
Navigate to the $INST_TOP/certs/opmn directory.

Create a new directory named BAK.
Move the ewallet.p12 and cwallet.sso files to the BAK directory just created.
Copy the ewallet.p12 and cwallet.sso files from the $INST_TOP/certs/Apache directory to the $INST_TOP/certs/opmn directory.
Step 7 - 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 certficate (server.crt from
previous step) to be present. Follow these steps to be sure these requirements are met:
1. Navigate to the $OA_JRE_TOP/lib/security directory.
2. Backup the existing cacerts file.
3. Copy your ca.crt and server.crt files to this directory and issue the following command to insure that cacerts has write permissions:
$ chmod u+w cacerts
4. Add your Apache ca.crt and server.crt to cacerts:

$ keytool -import -alias ApacheRootCA -file ca.crt -trustcacerts -v -keystore cacerts
$ keytool -import -alias ApacheServer -file server.crt -trustcacerts -v -keystore cacerts
If you were also provided an Intermediate Certificate (intca.crt) then you will also need to add that to the cacerts before
adding the server.crt:
$ keytool -import -alias ApacheRootCA -file ca.crt -trustcacerts -v -keystore cacerts
$ keytool -import -alias ApacheIntCA -file intca.crt -trustcacerts -v -keystore cacerts
$ keytool -import -alias ApacheServer -file server.crt -trustcacerts -v -keystore cacerts
When prompted, enter the keystore password (default password is "changeit").

When you have completed the modifications to the cacerts, reset the permissions:
$ chmod u-w cacerts
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 8 - Update the Context File
Use the E-Business Suite - Oracle Applications Manager (OAM) Context Editor to change the SSL related variables as shown in this table:
SSL Related Variables in the Context File
Variable
Non-SSL Value
SSL Value
s_url_protocol
http
https
s_local_url_protocol
http
https
s_webentryurlprotocol
http
https
3/07/2016 12:52 p. m.
Document 376700.1
9 de 26
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

s_webport
url constructed with https protocol and

s_webssl_port
Changes when using an SSL Accelerator

Variable
Non-SSL Value
SSL Value
s_url_protocol
http
http
s_local_url_protocol
http
http
s_webentryurlprotocol
http
https
s_active_webport
same as s_webport
value of the SSL Accelerator's external

interfacing port
s_webentryhost
same as s_webhost
SSL Accelerator hostname
s_webentrydomain
same as s_domainname
SSL Accelerator domain name
s_enable_sslterminator
remove the '#' to use ssl_terminator.conf in

ssl terminated environments
s_login_page

s_webport
url constructed with https protocol,

s_webentryhost, s_webentrydomain,
s_active_webport
s_external_url

s_webport
url constructed with https protocol,

s_webentryhost, s_webentrydomain,
s_active_webport
Step 9 - Run Autoconfig

Autoconfig can be run by using the adautocfg.sh script in the Application Tier $ADMIN_SCRIPTS_HOME directory.
Step 10 - Restart the Application Tier services

Use the adapcctl.sh script in the $ADMIN_SCRIPTS_HOME directory to stop and restart the Application Tier Apache services.
Step 11 - Disable Older SSL Protocols and Weak Ciphers

Implement the steps outlined in Document 1937646.1 for the SSL V3.0 "POODLE" Vulnerability.
Section 4: Database Tier Setup

Oracle products such as Oracle Configurator, Order Management, iStore, Order Capture, Quoting, iPayment, iStore, and Pricing access data
over the Internet in HTTP or HTTPS connection mode. The implementation of SSL 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 also SSL enabled.
To enable HTTPS Client request from the Database via 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 the sites
you need UTL_HTTP to connect to.
1. After setting your environment for the database tier, navigate to the $ORACLE_HOME/appsutil directory.
2. Create a new wallet directory named: wallet
3. Navigate to the newly created wallet directory.
3/07/2016 12:52 p. m.
Document 376700.1
10 de 26
4. Open the Wallet Manager as a background process:

owm &
5. On the Oracle Wallet Manager Menu navigate to Wallet -> 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?
6. If you need to import ca.crt:
On the Oracle Wallet Manager menu navigate to Operations -> Import Trusted Certificate.
Click OK.
Double click on ca.crt to import it.
7. Save the wallet:
On the Oracle Wallet Manager Menu click Wallet.
Verify the Auto Login box is checked.
Click Save.
To test that the wallet is properly set up and accessible, login 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 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://www.oracle.com:4443','http://proxy.com:80', 'file:/d1/oracle/db/tech_st
/10.2.0/appsutil/wallet', null) from dual;
SQL>select utl_http.request('https://www.oracle.com:4443',null, 'file:/d1/oracle/db/tech_st/10.2.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.
Note: Oracle Database 11g Release 2 (11.2) and Oracle Database 12c enables Oracle Real Application Clusters (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.
Section 5: Advanced SSL Configuration (Optional)

In Oracle E-Business Suite Release 12 the Oracle Application Server environment is managed by OPMN (Oracle Process Monitoring and
Notification services) which is a set of processes that include the Oracle HTTP Server (Apache) and OC4J containers (where J2EE processes
run). In Oracle E-Business Suite Release 12.1 we have introduced support for secure communication between these layers. This advanced
configuration should only be done on top of the basic SSL configuration.
The instructions in this section are for the Oracle Application Server.
OC4J supports SSL communication between Oracle HTTP Server and OC4J using AJPS. This is the secure version of Apache JServ Protocol
which is the protocol that Oracle HTTP Server uses to communicate with OC4J.
Note: The AJPS protocol used between Oracle HTTP Server and OC4J is not visible to the end user
There are 3 certificate options available to you when you creating your keystore for the Advanced SSL Configuration:
3/07/2016 12:52 p. m.
Document 376700.1
11 de 26
1. Self-Signed Certificates
Self-signed certificates are appropriate to use for testing the Advanced SSL configurations. These are sometimes also used for
Advanced SSL Configuration in a production environment where you are effectively your own client. Be sure you understand the
limitations of self-signed certificates when using them in any environment.
2. Certificates signed by the OracleAS Certificate Authority (see Section 8) .
These certificates were designed to be used within your Oracle Application Server environment.
3. Certificates signed by a Certificate Authority such as Verisign, Thawte, etc.
These certificates are appropriate for use in any environment and provide the highest level of security.
Some steps will be slightly different if you are using Self-Signed Certificates. When a step contains a section for both Self-Signed Certificates
and Certificates Signed by a Certificate Authority (includes OracleAS Certificate Authority, Versign, Thawte, etc) be sure to follow the steps in
the appropriate section.

1. Logon to the application tier as the OS user who owns the application tier files.
2. Source your application tier environment file (APPS<sid_machine>.env) located in the APPL_TOP directory.
3. Navigate to the $INST_TOP/ora/10.1.3 and source the <sid_machine>.env file to set your 10.1.3 ORACLE_HOME variables.
Step 2 - Create your java keystore

1. Navigate to the web ssl directory as defined in the context file:
$ grep s_web_ssl_directory $CONTEXT_FILE
Note: Unless you have changed the default settings this should be the same directory as $INST_TOP/certs which we will use in
subsequent steps to identify this directory. This directory defines the location where private keys and certificate files are stored.
2. Create a new directory with the name j2ee and then change to this directory.
$ mkdir j2ee
$ cd j2ee
3. Determine the values for the following parameters which will be used when you create the keystore for your instance:
Parameter
Value
server
name of the server where you are creating the

keystore
domain
the fully qualified domain of the server
password
In Release 12 the default keystore password is

"changeit". Please make note of your password as
you will need it when changing the default
password in Step 5.
name of your Organization
your City or Locality
ST
your State or Province
your 2 letter Country Code
4. Create your keystore by entering the following command all on 1 line substituting the appropriate parameters (in bold) for your
instance:
$ keytool -keysize 2048 -genkey -keyalg RSA -sigalg SHA256withRSA -keystore server.jks
-keypass password -storepass password -validity 365 -dname "CN=server.domain, OU=JKS, O=O,
ST=ST, C=C"
3/07/2016 12:52 p. m.
Document 376700.1
12 de 26
You should now see the file <server>.jks in your directory.

Note: We are using OU=JKS to distinguish this certificate from the Apache certficate. Since we have not specified an alias the default
alias "mykey" will be used.
Step 3 - Create your Certificate Request

A. Self-Signed Certificates
This step is not applicable for self-signed certificates. If using self-signed certificates proceed to Step 4.
B. Certificates Signed by a Certificate Authority
To generate a certificate request enter the following command all on 1 line substituting the appropriate parameters (in
bold) for your instance:
$ keytool -certreq -keyalg RSA -keystore server.jks -file server.csr
Submit the file server.csr to your Certificate Authority.
Note: If your using Thawte as your Certificate Authority you should check the box:
PKCS #7 Select this option for servers that use Java JDK keystore - including Tomcat and Jetty."
When you receive your signed certificate copy it to this directory ($INST_TOP/certs/j2ee) as jks_server.crt along with the Certificate
Authority's root certificate which should be re-named jks_ca.crt and the Authorities intermediate certificate (if applicable) which should be
renamed jks_intca.crt.
Note: We are naming the certificate jks_server.crt to distinguish it from the Apache server.crt
If you want to create jks_ca.crt and/or jks_intca.crt using your jks_server.crt file you can do so by following the directions in Section 7:
Creating your Certifying Authority's Certificate.
Step 4 - Add your Signed Certificate to the Keystore

A. Self-Signed Certificates
This step is applicable only if you are using self-signed certificates.
If your certificates were signed by a Certifying Authority continue with Step 4 B.
1. You will not have a signed certficate to add to the keystore. You will sign the certificate in the keystore using the
keytool's selfcert command. Enter the following all on 1 line substituting the appropriate parameters (in bold)
for your instance:
$ keytool -selfcert -keystore server.jks -keypass password -storepass password
-dname "cn=server.domain, ou=OU, o=O, c=C"
2. After signing the certificate you will need to extract the certificate so it can be imported into the Apache and
OPMN wallets This will be done using the keytool list command:
$ keytool -list -rfc -keystore server.jks -storepass password

This command will return the following information:
Alias name: mykey
Creation date: Nov 21, 2007
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
-----BEGIN CERTIFICATE----MIICCzCCAXSgAwIBAgIER0SUrjANBgkqhkiG9w0BAQUFADBKMQswCQYDVQQGEwJVUzEMMAoGA1UE
ChMDVFhLMQwwCgYDVQQLEwCBDAcxHzAdBgNVBAMTFmFwNjY2d2dzLnVzLm9yYWNsZS5jb20wHhcN
MDcxMTIxMjAyNzI2WhcNMDgwMjE5MjAyNzI2WjBKMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDVFhL
MQwwCgYDVQQLEwNBVEcxHzAdBgNVBAMTFmFwNjY2d2dzLnVzLm9yYWNsZS5jb20wgZ8wDQYJKoZI
3/07/2016 12:52 p. m.
Document 376700.1
13 de 26
hvcNAQEBBQADgY0AMIGJAoGBALaNY6QpChZPem7nXF7NJ5tmW1UFNqOgVW37fW4YiJH10yHKMLhB
zx6z9QxuJiNKiNzjckJ4KfnLp8xG58lZlubKPSei7yz1KJxeM8j39NbbIifsPYfqtT/EPdDDGK+B
kg0lK4c09TvxL93y0mFW7IG0PyqB0/ZTnBAcv2Fdyrg
/AgMBAAEwDQYJKoZIhvcNAQEFBQADgYEA
R/EeD4iJXuYV5eQmkp64D/aguNeyGu4qn67tU+iGDjDNtaO1qTPbTiDngD
/H8WpPjmxPcJxszp6z
fcKsFVgNmUC4js5U3DGA8Bcdl1ZGYvP7PUU0wZceHjD+KBB1sdV8KzL94OW41/RPXXUxIW6/UHRP
huFcDlIK2ExiXu7c5vw=
-----END CERTIFICATE----Copy the lines from -----BEGIN CERTIFICATE----- to -----END CERTIFICATE----- as indicated in bold.
Using the text editor of your choice, save these lines as jks_ca.crt.
B. Certificates Signed by a Certificate Authority
This step is not applicable if you are using self-signed certificates - continue with "C. Either Type Certificate"
In Step 3 you copied jks_ca.crt, jks_intca.crt, and jks_server.crt to the $INST_TOP/certs/j2ee directory. Now you will
use the import command to add it to the keystore substituting the appropriate parameters (in bold) for your instance
:
$ keytool -import -alias myca -keystore server.jks -storepass password -file
jks_ca.crt
$ keytool -import -alias myintca -keystore server.jks -storepass password -file
jks_intca.crt
$ keytool -import -keystore server.jks -storepass password -file jks_server.crt
Enter "yes" when prompted with: Trust this certificate? [no]: yes
Note: You may not have an intermediate ca certificate. It will depend on the Certifying Authority and certificate type. If an intermediate
ca certificate has been provided then this will also need to be imported with the root certificate.
We are not specifying an alias when importing jks_server.crt. The default alias "mykey" will be used. (This is because the -dname on the
certificate matches the -dname on the key generated when the keystore was created.)
You can use either of the following commands to see the contents of your keystore. The -list command by
default prints the MD5 fingerprint of a certificate. If the -v option is specified, the certificate is printed in humanreadable format:
$ keytool -list -keystore <keystore> -storepass <password>
$ keytool -list -v -keystore <keystore> -storepass <password>
For more information on the keytool see:http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/keytool.html

C. Either Type Certificate
This step is applicable for both self-signed certificates and certificates which have been signed by a certifying authority.
If you used a different Certificate Authority for your Apache Wallet than you used for the j2ee Java Keystore you will
need to import the Apache Wallet's root CA Certificate into the keystore so it will be recognized as a trusted Certifying
Authority. If this is not done, you will get handshake errors. To import a the certificate for a Certifying Authority into
your keystore:
1. Copy the $INST_TOP/certs/Apache/ca.crt file to the $INST_TOP/certs/j2ee directory.
2. Use the keytool import command to add ca.crt to the keystore:
$ keytool -import -alias ApacheCA -file ca.crt -trustcacerts -v -keystore
server.jks -storepass password
Enter "yes" when prompted with: Trust this certificate? [no]: yes
Step 5 - Add the Keystore CA Certificates to the Apache and OPMN Wallets (conditional)
This step is only necessary if you have used self-signed certificates to create the keystore OR you used different Certifying Authorities for the
keystore and Apache Wallet.
3/07/2016 12:52 p. m.
Document 376700.1
14 de 26
1. Copy $INST_TOP/certs/j2ee/jks_ca.crt to both the $INST_TOP/certs/Apache and $INST_TOP/certs/opmn directories.

2. Add jks_ca.crt it to each wallet using the orapki command line interface:
$ orapki wallet add -wallet . -trusted_cert -cert jks_ca.crt -pwd <your wallet password>

Use the E-Business Suite - Oracle Applications Manager (OAM) Context Editor to change the SSL related variables as shown in
this table:
Advanced SSL Related Variables in the Context File
Variable
Non-SSL Value
Advanced SSL Value
s_oc4j_secure
false
true
s_ajp_protocol
ajp
ajps
s_forms_tracking_cookies disabled
enabled
s_oc4j_ssl
on
off
Step 7 - Run Autoconfig

If you have upgraded to Release 12.1 by applying the 12.1 patchset to a previous release you will need to delete the following files so that
the new versions will be instantiated when autoconfig is run. If you have made any customizations to these files (custom user credentials,
etc) be sure to back the files up before deleting so you can re-add your customizations to the new files.
$ORA_CONFIG_HOME/10.1.3/j2ee/oacore/config/system-jazn-data.xml
$ORA_CONFIG_HOME/10.1.3/j2ee/forms/config/system-jazn-data.xml
$ORA_CONFIG_HOME/10.1.3/j2ee/oafm/config/system-jazn-data.xml
Note: Deleting these 3 files is not necessary if you used the 12.1 Rapid Install.
1. Use the adstpall.sh script in the Application Tier $ADMIN_SCRIPTS_HOME directory to stop all services.
2. Run autoconfig using the adautocfg.sh script in the Application Tier $ADMIN_SCRIPTS_HOME directory.
3. Update the newly instantiated files with your previous customizations if required.
Step 8 - Update the Keystore Password in the system-jazn-data.xml files

Navigate to the $ORA_CONFIG_HOME/10.1.3/j2ee/oacore/config directory and follow these steps:
1. Open the system-jazn-data.xml file in the editor of your choice.
2. Find the lines in the <users> section that read:
<user>
< name>oc4jkeystoreadmin</name>
<display-name>OC4J keystore admin user</display-name>
<guid>7D1943D0AF0411DC8F65CFCE4073EF3D</guid>
<description>E-Business OC4J keystore admin user</description>
< credentials>{903}Gfqv+nvfuUrfiQpcW7XcpptrOknyC0nj< credentials>
</user>
Note: The guid and credentials will be different on your system.
3. Change the < credentials> line to read:
3/07/2016 12:52 p. m.
Document 376700.1
15 de 26
< credentials>!password< credentials>
where password = the password you assigned when you created your keystore. Be sure to include the !.
This will encrypt the password the next time the service is started.
4. Save the file and exit.
Example: <user>
<name>oc4jstore</name>
<display-name>OC4J keystore admin user</display-name>
<guid>7D1943D0AF0411DC8F65CFCE4073EF3D</guid>
<description>E-Business OC4J keystore admin user</description>
<credentials>!password<credentials>
</user>
B. Navigate to the $ORA_CONFIG_HOME/10.1.3/j2ee/oafm/config directory and repeat steps 1-4.
C. Navigate to the $ORA_CONFIG_HOME/10.1.3/j2ee/forms/config directory and repeat steps 1-4.
Step 9 - Restart the Application Tier Services

Use the $ADMIN_SCRIPTS_HOME/adstrtal.sh script to restart the application tier services.
Advanced SSL Configuration for the Oracle Application Server is now complete. If there are any issues logging into E-Business Suite or
launching Forms these should be resolved before proceeding with Section 10: Encrypting database network traffic using ANO/ASO which is
optional.
Section 6: Converting Existing Certificates

If you have existing un-expired certificates from a previous implementation of SSL in Release 11i they can be converted and imported into a
wallet using the tools:
SSL2OSSL (Unix)
SSLCONVERT (Windows NT/2000)

1. Logon to the application application tier as the OS user who owns the application tier files.
2. Navigate to the $INST_TOP/ora/10.1.3 and source the <sid_machine>.env file to set your
10.1.3 ORACLE_HOME variables.
Step 2 - Copy your Certificates

Copy server.key, server.crt, and ca.crt to the $INST_TOP/certs/Apache directory.
Step 3 - Issue the command:

$ $ORACLE_HOME/Apache/Apache/bin/ssl2ossl -cert ./server.crt -key ./server.key -cafile ./ca.crt -wallet . -ssowallet yes
If your server certificate was issued by a Certifying Authority other than Verisign, Entrust, GTE, or RSA Data Security you'll also need to add
it to 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
Section 7: Obtaining your Certifying Authority's Certificate

To create ca.crt
1. Copy server.crt to your PC (if necessary) using one of the following methods:
3/07/2016 12:52 p. m.
Document 376700.1
16 de 26
Copy (in binary mode) server.crt to your pc

copy the contents of server.crt and paste into notepad on the PC. Save the file as server.crt
2.
3.
4.
5.
6.
7.
8.
9.
10.
Double click on server.crt to open it with the Crypto Shell Extension.

On the Certification Path tab click on the first (top) line and then View Certificate.
On Details tab click Copy to File, this will start the export wizard.
Click Next to continue.
Select Base-64 encoded X.509 (.CER) and click next.
Click Browse and navigate to the directory of your choice.
Enter ca.crt as the name and click ok to export the certificate.
Close the wizard.
Copy ca.crt back to your wallet directory (if necessary) using one of the following methods:
ftp (in binary mode) ca.crt to your application tier wallet directory
copy the contents of ca.crt and paste into a new file in your application tier wallet directory using a text editor. Save the
file as ca.crt
Section 8: Oracle Application Server Certificate Authority

The Oracle Application Server Certificate Authority is a Certificate Authority (CA) for use within your Oracle Application Server environment
where you are essentially both the client and the server. It is part of the Oracle Identity Management option and is bundled with the Oracle
Application Server 10g Enterprise Edition. It can also be licensed separately as an option for the Oracle Application Server 10g Standard
Edition.
For more information please refer to the Oracle Application Server Certificate Authority 10g White Paper.
Section 9: Information on SSL Protocol and Signature Algorithm Changes

Disabling Older SSL Protocols and Weak Ciphers
As a result of increased focus on security, there has been a gradual phasing out of weak ciphers and older protocols such as SSLv3 in favor
of more secure protocols such as TLS 1.0 or higher.
1. Review Note 387859.1 - Using AutoConfig to Manage System Configurations in Oracle E-Business Suite be sure you are comfortable
with and understand the concepts before proceeding.
2. Review Note SSL V3.0 "POODLE" Vulnerability for background information on the need to disable SSLv3, and Note 1937646.1 for
steps to remove SSLv3 and weak ciphers in Oracle E-Business Suite.
Note: Due to a limitation with the Oracle HTTP Server (OHS) 10g, only TLS 1.0 has been certified. Use of TLS 1.1 and 1.2 is still
pending at this time. Any change in this certification will be updated in this space.
Signature Algorithm Changes
Note: SHA-2 signed PKI certificates are now certified with the Oracle HTTP Server for Oracle E-Business Suite 12.1.3. You must apply
the minimum requirements when using SHA-2 signed PKI certificates. Minimum requirements include the following:
- Apply at least the October 2015 CPU to FMW 10.1.3.5 as per Document 2051000.1. Oracle E-Business Suite always recommends you
apply the latest CPU.
- For AIX and HP Itanium only, also apply patch 21948197 to FMW 10.1.3.5.
- For Windows only, also apply patch 22251660 to FMW 10.1.3.5.
- OpenSSL version 0.9.8za or higher.
If you are enabling SSL/TLS for the first time, follow steps in Section 3. If you are updating to a SHA-2 signed PKI certificate, perform
the steps listed in Section 11.
For HP Itanium and Windows only, reference the steps noted for the mkwallet command, as opposed to the Oracle Wallet Manager,
as these are required for these platforms.
Testing is performed with all CPU patches applied across the technology stack components and the Oracle E-Business Suite. You can
3/07/2016 12:52 p. m.
Document 376700.1
17 de 26
apply the October 2015 CPU (Patch 21845960) to FMW 10.1.3.5 without applying the October 2015 CPU to all components; however,
we recommend that customers apply the latest CPU across all technology stack components and the Oracle E-Business Suite.
Depending on your certificate provider, they may not accept MD5 based certificate requests (CSR) generated by Oracle Wallet Manager
(OWM). For example, VeriSign 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. The workaround is to make use of openssl to generate the
CSR. An example of this process is provided here:
1) Generate your CSR using the OWM as this will also create the key pair, and save the wallet.
2) Use openssl to extract the private key from the wallet in order to create a CSR for the key(pair) that is in the wallet:
openssl pkcs12 -in ewallet.p12 -nodes -out nonoracle_wallet.pem
3) Use openssl to generate the request specifying SHA-2:
openssl req -new -key nonoracle_wallet.pem -sha256 -out certrequest.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.
Do not specify a 'challenge password' as this has been deemed to be insecure by most certifying authorities.
4) Remove the PEM format file:
rm nonoracle_wallet.pem
5) Send this CSR to your Certifying Authority.

6) Upon receiving your newly issued certificate, you can import this into your wallet using OWM continuing with Section 3, Step 5.
For HP Itanium and Windows only:

1) Use openssl to extract the private key from the wallet in order to create a CSR for the key(pair) that is in the wallet:
openssl pkcs12 -in ewallet.p12 -nodes -out nonoracle_wallet.pem
2) 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 earlier.
Do not specify a 'challenge password' as this has been deemed to be insecure by most certifying authorities.
3) Remove the PEM format file:
rm nonoracle_wallet.pem
4) Send this CSR to your Certifying Authority.

5) Upon receiving your newly issued certificate, you can import this into your wallet continuing with Section 3, Step 5 for the mkwallet
command.
Reference the following notes for more information:

Note 1448161.1 How To Produce CSR With A SHA-1 Or Better Signature Algorithm
Note 1939223.1 Is it Possible to Generate SHA-2 Certificate Signing Requests with Oracle Wallet Manager or ORAPKI in FMW11g
3/07/2016 12:52 p. m.
Document 376700.1
18 de 26
Section 10: Encrypting database network traffic using ANO/ASO (Optional)

TNS (Transparent Networking Substrate) is an Oracle protocol that runs on top of a number of supported network protocols, including
TCP/IP. To configure Oracle E-Business Suite Release 12 to encrypt network traffic sent via TNS requires use of the Advanced Networking
Option (ANO). ANO is supplied as part of the Advanced Security Option (ASO) of the Oracle Database, which is shipped with Oracle
E-Business Suite Release 12.
Note: This configuration is certified for Oracle E-Business Suite using Forms Listener Servlet (the default mode) on all certified Oracle
E-Business Suite platforms (including database only platforms). To view specific release and platform support, go to Certifications on My
Oracle Support and search for Oracle E-Business Suite certifications against 'Advanced Security' and 'Advanced Networking Option'.
Advanced security encryption can be configured, based on a combination of client and server configuration parameters as REJECTED,
ACCEPTED, REQUESTED or REQUIRED.
The following matrix - taken from the database documentation - shows how a connection attempt will succeed or fail to provide an
encrypted connection with various combinations of the ENCRYPTION variable in the sqlnet.ora file on client and server.
Client
REJECTED
S
e ACCEPTED
r
v
e REQUESTED
r
REQUIRED
REJECTED
ACCEPTED
REQUESTED
REQUIRED
OFF
OFF
OFF
No Connection
OFF
OFF
ON
ON
OFF
ON
ON
ON
No Connection
ON
ON
ON
Oracle has certified Oracle E-Business Suite Release 12 with the server parameter set to REQUIRED - this ensures that all Oracle
E-Business Suite Release 12 TNS network traffic is being encrypted.
Although ANO/ASO supports a number of different encryption algorithms, the supported algorithms are version dependent. For Oracle
E-Business Suite Release 12 certification the the server's preference is set to AES256, AES192, 3DES168.
Appendix A - Using Network Traffic Encryption contains information on Enabling Trace, Verifying ANO is Functioning Correctly, and the Types
of Encryptions Allowed and Supported.
The remainder of this section will help you enable the encryption in each of the different ORACLE_HOMEs in an Oracle E-Business Suite
Release 12 deployment.
Step 1 - Apply CPU Patch 12837860
Ensure the 10.1.2 Oracle Home is at patch level 10.1.2.3 before applying CPU Patch 12837860.
1. Upgrade to Oracle Application Server 10.1.2.3 (as detailed in 'Upgrading OracleAS 10g Forms and Reports in Oracle E-Business Suite
Release 12' My Oracle Support Knowledge Document 437878.1).
2. Apply CPU Patch 12837860 to the 10.1.2.3 Oracle Home (as detailed in "Section 3.1.6 Oracle Fusion Middleware Utilities for Oracle
Databases" in "Patch Set Update and Critical Patch Update October 2011" My Oracle Support Knowledge Document 1346104.1).
Note: No CPU patch needs to be applied to the 10.1.3 Oracle Home used by the Oracle HTTP Server.
Step 2 - Relink FND Executables
All 'FND' executables need to be relinked:
1. Run adadmin
2. When the Main Menu appears select 'Maintain Applications Files Menu' and then select 'Relink Applications Program'.
3. Answer the questions below as follows, in order to select the individual executables for relinking.
3/07/2016 12:52 p. m.
Document 376700.1
19 de 26
Enter list of products to link ('all' for all products)[all] : fnd

Generate specific executables for each selected product [No] ? y
Relink with debug information [No] ? n
(You will then be offered a list of executables that are available for relinking)
Enter executables to relink, or enter 'all' [all] all
Step 3 - Shutdown Application Tier Server Processes and Database Listener
On each application tier server, shut down all processes or services:
$ $ADMIN_SCRIPTS_HOME/adstpall.sh <apps user> / <apps password>
On the database server node, shut down the database listener:
$ $ORACLE_HOME/appsutil/scripts/<sid_machine>/addlnctl.sh stop <ORACLE_SID>
Oracle E-Business Suite will be unavailable to users until the remaining tasks in this section are completed.
Step 4 - Database Tier Changes

1.
2.
3.
4.
Logon to the Database Tier server as the file system owner.

Source the Database Tier environment file located in Oracle Home directory.
Take a backup of the $TNS_ADMIN/sqlnet_ifile.ora file.
Open the $TNS_ADMIN/sqlnet_ifile.ora file with the editor of your choice and add the following lines.
SQLNET.ENCRYPTION_TYPES_SERVER=(AES256, AES192, 3DES168)
SQLNET.ENCRYPTION_SERVER=REQUIRED
After the changes have been made, restart the listener:
$ $ORACLE_HOME/appsutil/scripts/<sid_machine>/addlnctl.sh start <ORACLE_SID>
Step 5 - Create $TNS_ADMIN/sqlnet.ora and sqlnet_ifile.ora files on each Application Tier

By default, the Oracle E-Business Suite Release 12 Application Tier installations do not have either a sqlnet.ora or
sqlnet_ifile.ora file so we will need create these. We keep the ANO/ASO directives in the sqlnet_ifile.ora file to isolate it from
any future autoconfig updates that affect the sqlnet.ora file.
1.
2.
3.
4.
Logon to the Application Tier server as the file system owner.

Source your application tier environment file (APPS<sid_machine>.env) located in the APPL_TOP directory.
Navigate to the $TNS_ADMIN directory.
Use the editor of you choice to create the sqlnet.ora file with the following lines:
###############################################################
#
# sqlnet.ora file for application tier sqlnet encryption with Advanced SSL Configuration
#
###############################################################
IFILE = <full path to TNS_ADMIN>/sqlnet_ifile.ora
Use the editor of you choice to create the sqlnet_ifile.ora file with the following lines:
###############################################################
#
# sqlnet_ifile.ora for application tier sqlnet encryption with Advanced SSL Configuration
#
###############################################################
SQLNET.ENCRYPTION_TYPES_CLIENT=(AES256, AES192, 3DES168)
SQLNET.ENCRYPTION_CLIENT=REQUIRED

Use the E-Business Suite - Oracle Applications Manager (OAM) Context Editor to change the SSL related variables on each
3/07/2016 12:52 p. m.
Document 376700.1
20 de 26
application tier server as shown in this table:

Advanced SSL Related Variables in the Context File
Variable
Non-SSL
Value
s_custom_dbc_params
Advanced SSL Value

ENCRYPTION_CLIENT=REQUIRED ENCRYPTION_TYPES_CLIENT=
(3DES168)
Note: This step sets the configuration for JDBC client connections and is optional. If the value is not set, and the parameter on the
database tier is set to REQUIRED, the JDBC client connection value will be ACCEPTED (which is the default value). As long as an
encryption or integrity algorithm match is found, the connection will continue without error and the security service will remain enabled.
Step 7 - Run Autoconfig (conditional)

If you updated the context file in Step 4 you now need to run autoconfig on each application tier server:
$ $ADMIN_SCRIPTS_HOME/adautocfg.sh appspass=<apps password>
Check the autoconfig log file for errors.
Step 8 - Restart the Application Tier Services

On each application tier server, restart all processes and services:
$ $ADMIN_SCRIPTS_HOME/adstrtall.sh <apps user> / <apps password>
Section 11: Renewing Revoked or Expired Certificates

This section covers the case where you have an existing SSL/TLS instance and only need to renew your certificate. This may be the result of
needing to have a certificate revoked, or the certificate has expired. In the case where the certificate request remains unchanged, it will only
require the original certificate request to renew the certificate. However, following the best practices for security, it is generally
recommended that a new private key along with a new CSR be generated.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Update your instance to support SHA-2 signed PKI certificates as noted in Section 9 Signature Algorithm Changes.
Backup 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 (OWM) from the 10.1.3 Oracle Home.
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 OWM.

1.
2.
3.
4.
5.
Update your instance to support SHA-2 signed PKI certificates as noted in Section 9 Signature Algorithm Changes.
Backup the existing wallet and any associated files in your wallet directory.
Proceed with Section 3, Step 2 in order to generate a new wallet and CSR.
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.
3/07/2016 12:52 p. m.
Document 376700.1
21 de 26
mkwallet -i <wallet password> .

ca.crt
mkwallet -i <wallet password> . intca.crt
mkwallet -i <wallet password> . server.crt
NZDST_CLEAR_PTP
NZDST_CLEAR_PTP
NZDST_CERTIFICATE
## root CA cert
## intermediate CA cert
## server cert
With the wallet now updated with the new certificate, you will also need to update the rest of the SSL/TLS setup by following Section 3, Step
5 starting with the update to the b64InternetCertificate.txt file and then following Step 6 and Step 7 in the same section. The steps in
Section 4 for the database would only be required if the root certificate was updated as part of your newly issued certificate. You only need
to import the root certificate as a 'Trusted Certificates' into the wallet used by the database.
Appendix A - Using Network Traffic Encryption

1. How to Enable Tracing
Tracing can both help verify that encryption is active, and help diagnose the cause of any errors.
TRACE LEVEL can be set to the level of tracing required. The TNS Listener must be restarted for the trace setting to take effect.
To enable tracing, the following parameters should be added to the sqlnet.ora file:
TRACE_DIRECTORY_SERVER= <a directory to which the OS user running the listener can write>
TRACE_LEVEL_SERVER= 16
TRACE_UNIQUE_SERVER= ON
Note: tracing at this level generates many large files in the trace directory. You should only run in tracing mode while verifying that
encryption takes place. Once satisfied that TNS traffic is indeed encrypted, uncomment (or remove) the lines relating to tracing from
sqlnet.ora file and bounce the tnslistener.
2. Verifying that ANO is Functioning Correctly
After enabling tracing, check the trace files in the appropriate directories to verify that ANO functionality is in use:
Review the resulting sqlnet trace (.trc) files.
In the trace directory you will see a number of trace files with names such as svr_NNNNN.trc.
Below is section of a trace file where encryption is being successful used:
....
na_tns: authentication is not active
na_tns: encryption is active, using 3DES168
na_tns: exit
....
If you have not defined a tnsnav.ora file, then the following message will appear in the sqlnet trace (.trc) file and can be safely
ignored:
nrigbni: Unable to get data from navigation file tnsnav.ora
Some of the trace files are small (approximately 3kb) and do not contain any information concerning enabled encryption.
These files are generated for connections that originate from the database and do not traverse the network. These files will be
generated even when only the database and its listener are running.
$ cd $TNS_ADMIN/../../trace
$ ls -ltr |
-rw-r--r--rw-r--r--rw-r--r--
awk '$5 > 3000 && $5

1 oracle dba
3601
1 oracle dba
3062
1 oracle dba
3062
< 4000' | tail -3

Sep 24 13:57 svr_13815.trc
Sep 24 13:58 svr_13817.trc
Sep 24 13:59 svr_13819.trc
Other files are larger, some quite large, and they will contain "encryption is active, using CRYPTOALGORITHM..." messages.
There will be two different algorithms in use, 3DES168 and AES256:
$ cd $TNS_ADMIN/trace
3/07/2016 12:52 p. m.
Document 376700.1
22 de 26
$ ls -ltr | tail -3
-rw-r--r-- 1 oracle dba 28427064 Sep 24 14:20 svr_11547.trc
$ grep 'encryption is active' svr_29270.trc svr_29270.trc svr_29144.trc

svr_29270.trc:[20-SEP-2007 16:47:20:369] na_tns: encryption is active, using 3DES168
svr_29270.trc:[20-SEP-2007 16:47:20:369] na_tns: encryption is active, using 3DES168
svr_29144.trc:[20-SEP-2007 16:46:48:914] na_tns: encryption is active, using AES256
The connections using AES256 are generated by the executables linked to the OCI C libraries (sqlplus, FNDLIBR, RCVOLTM,...)
and the 3DES168 connections originate from the connections via the JDBC interface.
3. Types of Encryptions that are Allowed and Supported
The following section - based on the Oracle Database documentation - describes how the selection of encryption algorithms is
performed on a per-connection basis. You do not have to use this information, you can instead simply use the configuration examples
provided earlier in this document. However, you will have to create your own configuration files if you wish to use different algorithms
or have third party tools that do not support encryption.
ACTIVATING ENCRYPTION AND INTEGRITY

In any network connection, it is possible for both the client and server to each support more than one encryption algorithm and more
than one integrity algorithm. When a connection is made, the server selects which algorithm to use, if any, from those algorithms
specified in its sqlnet.ora file.
The server searches for a match between the algorithms available on both the client and the server, and picks the first algorithm in
its own list that also appears in the client list. If one side of the connection does not specify an algorithm list, all the algorithms
installed on that side are acceptable. The connection fails with error message ORA-12650 if either side specifies an algorithm that is
not installed.
Encryption and integrity parameters are defined by modifying the sqlnet.ora file on the clients and the servers on the network.
You can choose to configure any or all of the available Oracle Advanced Security encryption algorithms and either or both of the
available integrity algorithms Only one encryption algorithm and one integrity algorithm is used for each connect session.
Note: Advanced Security selects the first encryption algorithm and first integrity algorithm enabled on the client and the server. Oracle
recommends that you select algorithms and key lengths in the order in which you prefer negotiation - ideally with the strongest key
length first.
Set the SQLNET.ENCRYPTION_TYPES_SERVER and SQLNET.ENCRYPTION_TYPES_CLIENT accordingly based on your current level of
the jdbc thin driver. Otherwise you could encounter TNS-12599 errors. The alternative is to upgrade to the most current jdbc thin
driver in order to allow usage of the higher encryption algorithm. The following lists the jdbc version and the equivalent supported
encryption algorithm:
Supported 10.2 jdbc thin encryption algorithms:
3DES168: 3-key 3DES
3DES112: 2-key 3DES
DES56C: DES 56-bit key CBC
DES40C: DES 40-bit key CBC
RC4_256: RC4 256-bit key
Supported 11.x jdbc thin encryption algorithms:
10.2 algorithms above plus:
AES256: AES 256-bit key
NEGOTIATING ENCRYPTION AND INTEGRITY
3/07/2016 12:52 p. m.
Document 376700.1
23 de 26
To negotiate whether to turn on encryption or integrity, you can specify four possible values for the Oracle Advanced Security
encryption and integrity configuration parameters. The four values are listed in the order of increasing security. The value
REJECTED provides the minimum amount of security between client and server communications, and the value REQUIRED
provides the maximum amount of network security:
REJECTED
ACCEPTED
REQUESTED
REQUIRED
The default value for each of the parameters is ACCEPTED.
REJECTED
Select this value if you do not elect to enable the security service, even if required by the other side.
In this scenario, this side of the connection specifies that the security service is not permitted. If the other side is set to
REQUIRED, the connection terminates with error message ORA-12650. If the other side is set to REQUESTED, ACCEPTED, or
REJECTED, the connection continues without error and without the security service enabled.
ACCEPTED
Select this value to enable the security service if required or requested by the other side.
In this scenario, this side of the connection does not require the security service, but it is enabled if the other side is set to
REQUIRED or REQUESTED. If the other side is set to REQUIRED or REQUESTED, and an encryption or integrity algorithm
match is found, the connection continues without error and with the security service enabled. If the other side is set to
REQUIRED and no algorithm match is found, the connection terminates with error message ORA-12650.
If the other side is set to REQUESTED and no algorithm match is found, or if the other side is set to ACCEPTED
or REJECTED, the connection continues without error and without the security service enabled.
REQUESTED
Select this value to enable the security service if the other side permits it.
In this scenario, this side of the connection specifies that the security service is desired but not required. The security service
is enabled if the other side specifies ACCEPTED, REQUESTED, or REQUIRED. There must be a matching algorithm available on
the other side otherwise the service is not enabled. If the other side specifies REQUIRED and there is no matching algorithm,
the connection fails.
REQUIRED
Select this value to enable the security service or preclude the connection.
In this scenario, this side of the connection specifies that the security service must be enabled. The connection fails if the
other side specifies REJECTED or if there is no compatible algorithm on the other side.
The following table shows whether the security service is enabled, based on a combination of client and server configuration
parameters. If either the server or client has specified REQUIRED, the lack of a common algorithm causes the connection to
fail. Otherwise, if the service is enabled, lack of a common service algorithm results in the service being disabled.
Encryption and Data Integrity Negotiation Table
Client
REJECTED
S
e
r
v
e
r
ACCEPTED REQUESTED REQUIRED
REJECTED
OFF
OFF
OFF
Connection fails
ACCEPTED
OFF
OFF
ON
ON
REQUESTED
OFF
ON
ON
ON
3/07/2016 12:52 p. m.
Document 376700.1
24 de 26
REQUIRED
Connection fails
ON
ON
ON
Displaying the encryption options available from the Tools and Database ORACLE_HOME
After setting your environment to either the Tools or Database ORACLE_HOME using the "adapters" command:
$ . $ORACLE_HOME/bin/adapters
This will display a list of the encryption options available for the following:
a. Installed Oracle Net transport protocols

b. Installed Oracle Net naming methods
c. Installed Oracle Advanced Security options
The following errors may be safely ignored:
Error!!! SDP/IB is not completely installed!

Present in libntcp10, but missing from ntcontab.o...
Error!!! Oracle Names Server Naming is not completely installed!
Appendix B - Disabling SSL

There may be a need to temporarily disable SSL for testing or for troubleshooting purposes. In such cases, use the following procedure to
accomplish this, while at the same time not undermining the SSL configuration up to this point, and allowing SSL to be enabled again.
1. Refer to Step 8 and use the E-Business Suite - Oracle Applications Manager (OAM) Context Editor and change the context variables to
the Non-SSL Value noted in the table.
2. Run AutoConfig.
3. Use the adapcctl.sh script in the $ADMIN_SCRIPTS_HOME directory to stop and restart the Application Tier Apache services.
Change Log
Date
Description
February 16, 2016
- Added information on FMW requirements to Section 3 for client TLS 1.2 support.
- Removed reference to note 1275428.1, as information is misleading regarding current SHA-2
compatibility.
November 24, 2015
- Added updates for SHA-2 support of Windows.
November 20, 2015
- Added updates in Section 3 and Section 9 for SHA-2 support of HP Itanium, along with use of the
mkwallet command as an alternative.
- Updated Section 11 to make a note of the recommendation to generally generate a new private key
and CSR for security reasons.
- Added OpenSSL version minimum requirements.
3/07/2016 12:52 p. m.
Document 376700.1
25 de 26
October 27, 2015
- Doc Bug 22102576: Updated openssl command in Section 9 for SHA-2 and keytool command in
Section 5, Step 2 for SHA-2.
October 20, 2015
April 2, 2015
Added clarification for support of TLS 1.1 and 1.2.
January 29, 2015
Updated information on SHA-2 compatibility as well as workaround for MD5 based certificate requests.
December 26, 2014
Added information on SSL off-loading and support for self-signed/in-house/trial certificates.
October 23, 2014
Updated Section 9 with information on disabling older SSL protocols
June 10, 2014
- Published revised document to include all remaining comments, and all format and grammatical
changes.
May 15, 2014
Added Appendix B for steps on disabling SSL
Apr 30, 2014
- Updated Section 3, Step 5 to reference P7B certificates.

- Added paragraph under Section 1 referencing JRE and JAR file signing notes.
Apr 17, 2014
- Updated Note in Section 3, Step 5 to reference base64.

- Removed reference to s_help_web_agent from table in Section 3, Step 8.
- Added note to Section 3, Step 3 for converting CSR to SHA-1.
Apr 16, 2014
Added SSL Accelerator specific information
Dec 18, 2013
Added a forward reference to the SSL document for R12.2
Nov 22, 2011
CPU PATCH ADDED TO 376700.1 ASO/ANO SECTION
Nov 14, 2011
Certification specific details on DB ANO/ASO feature has been removed
Nov 11, 2011
Added some Feedback
Aug 12, 2010
Added Section 9 - Disabling SSL v2 and Weak Ciphers
Oct 28, 2009
Updated iHelp url settings.
May 1, 2009
Published 12.1 updates to Metalink
Dec 23, 2008
Processed remarks and added Certificate Provisioning for XML Publisher or Business Intelligence
Publisher.
Nov 3, 2008
Added ANO/ASO and Appendix A
Oct 7, 2008
Added Discoverer Notes.
July 17, 2008
Updated for Release 12.1 and Advanced SSL Configuration.
Nov 5, 2007
Added custom.conf section.
Oct 4, 2007
Added note that use of the Forms Server Listener with ConnectMode=https is not supported.
July 20, 2007
Modified SSL Accelerator changes.
Jan 24, 2007
Initial creation.
Doc Bug 21957788: Removed reference to rewrite rule for online help as it is no longer needed.
Expanded Section 2 with information on inbound, outbound, and loopback.
Updated Section 3 and Section 9 with information on SHA-2 support.
Added Section 11 for the certificate renewal process.
Added Step 11, Section 3 for disabling SSLv3.
Note 376700.1 by Oracle E-Business Suite Development

Copyright 2008, 2015, Oracle
3/07/2016 12:52 p. m.
Document 376700.1
26 de 26
REFERENCES
Didn't find what you are looking for?
3/07/2016 12:52 p. m.

Document 376700.1 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Document 376700.1 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Document 376700.

Enabling SSL or TLS in Oracle E-Business Suite Release 12 (Doc ID 376700.1)

Enabling SSL or TLS in Oracle E-Business Suite Release 12

Section 2: Concepts and Terminology

SSL uses 2 types of certificates:

How SSL works with Application Tier Oracle HTTP Server:

How SSL works with Oracle Database Server:

Certificate Authority (CA)

Certificate Signing Request (CSR)

Digital Certificate (Public Key)

Private (Server) Key

Global Server Certificates

Secure Socket Layer Accelerators

Section 3: Application Tier Setup

- Apply the October 2015 CPU (Patch 21845960).

Set Your Environment.

Step 1 - Set Your Environment

Step 2 - Create a wallet

4. On the Oracle Wallet Manager Menu navigate to Wallet -> New.

Step 3 - Create a Certificate Request

Fill in the appropriate values where:

Step 4 - Submit the Certificate Request to a Certifying Authority

Click on Certificate [Requested] to Highlight it.

Step 5 - Import your Server Certificate to the Wallet

2. From the menu click Wallet then Open.

Using the mkwallet command:

2. Verify the wallet contents:

3. Enable Auto_login for the wallet:

mkwallet -s <wallet password> .

## This will create cwallet.sso

Step 6 - Modify the OPMN wallet

Navigate to the $INST_TOP/certs/opmn directory.

Step 7 - Update the JDK Cacerts File

4. Add your Apache ca.crt and server.crt to cacerts:

When prompted, enter the keystore password (default password is "changeit").

url constructed with http protocol and

url constructed with https protocol and

url constructed with http protocol and

url constructed with https protocol and

Changes when using an SSL Accelerator

value of the SSL Accelerator's external

SSL Accelerator hostname

SSL Accelerator domain name

remove the '#' to use ssl_terminator.conf in

url constructed with http protocol and

url constructed with https protocol,

url constructed with http protocol and

url constructed with https protocol,

Step 9 - Run Autoconfig

Step 10 - Restart the Application Tier services

Step 11 - Disable Older SSL Protocols and Weak Ciphers

Section 4: Database Tier Setup

4. Open the Wallet Manager as a background process:

SQL>select utl_http.request('https://www.oracle.com:4443',null, 'file:/d1/oracle/db/tech_st/10.2.0/appsutil

Section 5: Advanced SSL Configuration (Optional)

Step 1 - Set Your Environment

Step 2 - Create your java keystore

name of the server where you are creating the

the fully qualified domain of the server

In Release 12 the default keystore password is

name of your Organization

your City or Locality

your State or Province