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

Enabling SSL in Oracle E-Business Suite Release 12.2 (Doc ID 1367293.1) To BottomTo Bottom 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: Encrypting Database Network Traffic Using ANO/ASO (Optional) Appendix A - Using Network Traffic Encryption Appendix B - Disabling SSL Appendix C - Known Issues This document details the steps for enabling SSL in Oracle E-Business Suite Release 12.2. The most current version of this document can be obtained in My Oracle Support Knowledge 1367293.1. Refer to My Oracle Support Knowledge 376700.1 for the setup steps for enabling SSL in Oracle E-Business Suite Release 12.0 and 12.1. There is a change log at the end of this document. Section 1: Introduction Oracle E-Business Suite Release 12.2 uses the Oracle Fusion Middleware infrastructure to secure communication between components using SSL. Oracle Fusion Middleware supports SSL version 3, TLS version 1 and JKS-based keystores for components running under Java and Oracle Wallets for other components, such as the Oracle HTTP Server. Oracle HTTP Server (Web Tier) is the Web Server component for Oracle Fusion Middleware and enables strong cryptography using mod_ossl and mod_wl_ohs modules. Web Tier certificates can still be managed by the Oracle Wallet Manager (OWM), which is accessible via the OWM graphical user interface, ORAPKI command line interface (CLI) or Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control). 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. Oracle E-Business Suite Release 12 uses the Sun Java Plugin. If you need to use HTTPS for the Forms communication layer you must use the servlet architecture. Oracle Fusion Middleware Oracle WebLogic Server allows additional Java Keystores to be created to protect the communication to and from Oracle WebLogic Servers (Application tier). These Java Keystores can be created with Java Keytool Utility or Fusion Middleware Control. This document provides information specific to securing Oracle E-Business Suite Release 12.2 components. Section 2: Concepts and Terminology Transport Layer Security (TLS) & Secure Sockets Layer (SSL) TLS and its predecessor SSL secures communication by providing message encryption, integrity and authentication. This document uses the term SSL where either SSL or TLS may be appropriate because SSL is the most widely recognized term. 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. Secure Socket Layer Offloading and Load Balancers Secure Socket Layer (SSL) Offloading can be used to remove the processing burden of encrypting/decrypting traffic from a Web Server. An SSL offloader that acts as an SSL terminator is responsible for converting HTTPS SSL requests to non-SSL HTTP requests, directing the request to the Web Server which is running in non-SSL mode. Any response back to the desktop is encrypted and returned to the client. Encryption/decryption of data can also be speeded up by using dedicated devices designed to perform SSL acceleration. These types of offloading and acceleration activities tend to be performed at the Load Balancer Layer but can also be standalone devices. If you’re planning on only using an SSL terminator (for example f5 BIG-IP achieves this through a Client SSL Profile) then only Steps 10 to 13 of Section 3: Application Tier Setup and Section 4: Database Tier Setup should be configured, additional sections are optional. Securing communication from an SSL Load Balancer to an SSL enabled Oracle E-Business Suite Release 12.2 instance is also becoming more common (for example f5 BIG-IP LTM achieves this through a Server SSL Profile). For this type of configuration additional steps will need to be taken to ensure the chain of trust is established between both sides. Note: Depending on the Load Balancer, the SSL Server configuration can be setup to presents its certificate to Oracle E-Business Suite Release 12.2 which in turn will verify it if the ‘SSLVerifyClient require’ directive is set for the Web Tier. For this setup you may need to import the Load Balancer certificate(s) into the Oracle Wallet as well as the JDK keystores (at the application tier and the database layer) to establish the chain of trust. In turn, if the Load Balancer is configured to verify the Oracle E-Business Suite Release 12.2 Server Certificate then the Oracle E-Business Suite Release 12.2 certificate(s) will need to be added to the Load Balancer trust point, refer to the Load Balancer documentation on how to do this. 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 an SSL Offloader 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 Offloader because it requires less maintenance as none of the application tier Web Nodes have to be configured for SSL anymore. Keystores and Wallets Oracle Fusion Middleware uses JKS keystore (the default JDK implementation of Java keystores used by Oracle WebLogic Server) to store keys and certificates. Other components (such as Oracle HTTP Server) continue to use the Oracle wallet as their storage mechanism. Wildcard Certificates Wildcard Certificates secure a website URL first level sub-domain that the certificate was issued to. Oracle WebLogic Server uses a Hostname Verifier to ensure the server being connected to via SSL is genuine for the request being made. The standard implementation of a hostname verifier in Oracle WebLogic for SSL requires an explicit Common Name (CN) match. Oracle E-Business Suite Release 12.2 deployment of Oracle WebLogic Server includes an enhancement to allow both Wildcard and Subject Alternative Name (SAN) support. This will allow Oracle WebLogic Server to communicate with external websites that use Wildcard certificates (for example My Oracle Support). Section 3: Application Tier Setup 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 Application 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. Note: Oracle E-Business Suite Release 12.2 is preconfigured with default self-signed certificates during the install. Using these or any other demo or self-signed certificates is not covered in this documentation. For simplicity any existing keystores are not used, and if your configuration included additional certificates that your deployment is dependent on for integration, you will have to take additional steps to ensure they are added afterwards (those steps are not covered in this document but would either consist of using the current keystore or re-importing them into a new keystore). The main steps for setting up SSL on the Application Tier are: Set Your Environment Create a Wallet Create a Certificate Request Submit the Certificate Request to a Certificate Authority Import your Server Certificate Modify the Oracle HTTP Server Wallet Modify the OPMN Wallet Fusion Middleware Control Console Update the JDK Cacerts File Update the Context File and Config Files Run AutoConfig Customizations Restart the Application Tier Services Synchronization between Run and Patch File System Note: Oracle Discoverer users who enable SSL for the Oracle E-Business Suite must also enable SSL for Discoverer, and should refer to Oracle Business Intelligence Discoverer. Step 1- Set Your Environment During the Oracle E-Business Suite Release 12.2 Installation, Rapid Install lays down two copies of the Oracle E-Business Suite File System. After the installation one of the File Systems will be labeled as the Run File System and the second one the Patch File System. As part of applying online patches to the system the Patch File System will be promoted to be the new Run File System and the old Run File System becomes the Patch File System for the next online patching cycle. Apply the latest AD and TXK Delta Release Update Packs. Refer to Note 1617461.1 for the latest information on known issues. Note: The steps detailed in this section must be executed on the (running) Run File System in order to ensure that during the next online patching the SSL setup is then propagated to the Patch File System. 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 Application Context file variable {s_file_edition_type} set to 'run' denotes the Run File System. Source your application tier environment file (.env), located in the APPL_TOP directory on the Run File System. Do not source the APPS.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 $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= :0.0 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 and not covered in this document. Step 2 - Create a wallet 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 the Wallet manager as a background process: owm & For Windows: The Oracle Wallet Manager can be launched from the run file system as follows: Start -> Run -> Input \webtier\bin\launch.exe "\webtier\bin" owm.cl and click OK. 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. 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. Click YES when prompted: “A new empty wallet has been created. Do you wish to create a certificate request at this time?” Step 3 - Create a Certificate Request After clicking "Yes" in step 2, 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: 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: SHA1 Hash Algorithm Migration for SSL Certificates issued with a SHA1 based signature hash algorithm as an industry standard are being phased out. Many sites are transitioning to SHA2 or higher ahead of industry plans for deprecation of SHA1. The time frame for moving to SHA2 may vary depending on the certificate authority used. This change also impacts intermediate certificates which must also be SHA2 in order to chain back to the end-entity SHA2 certificate issued. Root certificates are not impacted. 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 SHA1 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 SHA2 or above 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 here: 1) Generate your CSR using the OWM as this will also create the key pair, and save the wallet. 2) 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 3) Use openssl to generate the request specifying SHA2: 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) Send this CSR to your Certifying Authority. 5) Upon receiving your newly issued certificate, you can import this into your wallet using OWM continuing with Step 5 below. Reference the following notes for more information: Note 1448161.1 How To Produce CSR With A SHA-1 Or Better Signature Algorithm Note 1275428.1 Support Status for SHA2 in Oracle Application Server (10.1.2.X.X/10.1.3.X.X) and Fusion Middleware 11g (11.1.1.X) Note 1939223.1 Is it Possible to Generate SHA2 Certificate Signing Requests with Oracle Wallet Manager or ORAPKI in FMW11g Step 4 - Submit the Certificate Request to a Certificate Authority Export the Certificate Request: Click on Certificate [Requested] to Highlight it From the menu click Operations -> Export Certificate Request Save the file as server.csr (example filename) 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 check the Auto Login box Exit Wallet Manager The wallet directory will contain the following files: cwallet.sso ewallet.p12 server.csr The server.csr should now be submitted to your Certificate Authority to request a Server Certificate. Step 5 - Import your 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 filename) in the wallet directory on your server by one of the following methods: Use ftp (in binary mode) to copy the certificate Copy and paste the certificate contents into server.crt (example filename) Steps to import server.crt into your wallet: Open the Wallet Manager as a background process: owm & For Windows: The Oracle Wallet Manager can be launched from the run file system as follows: Start -> Run -> Input \webtier\bin\launch.exe "\webtier\bin" owm.cl and 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 On 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 on server.crt to import it. Save the wallet: On the Oracle Wallet Manager Menu click Wallet Verify the Auto Login box is checked Click Save 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 CA’s 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). If you need to import the CA Certificate you'll also need to add the contents of Server Certificate (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 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 ohs_instance_loc variable (details the ohs instance location) and the 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 from {s_web_ssl_directory}/Apache into the current directory. Step 7 - 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 {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. Step 8 - Fusion Middleware Control Console Fusion Middleware Control Console utilizes the functionality of OPMN to manage your Oracle Fusion Middleware Enterprise. Using a Web browser, 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 SSL 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 {s_ohs_instance_loc}/config/OPMN/opmn/wallet directory to all three locations previously mentioned. Step 9 - Update the JDK Cacerts File Oracle Fusion Middleware components (including Oracle WebLogic Server, Oracle Web Services) requires the Certificate of the Certificate 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 Oracle BI Publisher require the Server Certificate (server.crt from previous step) to be present. Follow the steps below for all Application Tier Nodes: 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. Backup the existing cacerts file. 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 Add your Oracle HTTP Server ca.crt and server.crt to cacerts: $ keytool -import -alias OHSRootCA -file ca.crt -trustcacerts -v -keystore cacerts $ keytool -import -alias OHSServer -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 OHSRootCA -file ca.crt -trustcacerts -v -keystore cacerts $ keytool -import -alias OHSIntCA -file intca.crt -trustcacerts -v -keystore cacerts $ keytool -import -alias OHSServer -file server.crt -trustcacerts -v -keystore cacerts When prompted enter the keystore password (the default password is "changeit"). Note: For Oracle E-Business Suite Release 12.2 installations that use 64-bit JDK for Oracle Fusion Middleware the steps in this section need to be repeated for the 32-bit JDK keystore location that is still used 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 {s_fmw_jdktop}/jre/lib/security so this additional step is not required. Step 10 - Update the Context File and Config Files In Oracle E-Business Suite Release 12.2 some configuration files are no longer maintained by AutoConfig (including httpd.conf and ssl.conf). Oracle Enterprise Manager 11g Fusion Middleware Control should be used to maintain these configuration files as well as making additional changes to Context File variables. When choosing the SSL port, special consideration should be given if a privileged port is being considered (for example 443 on UNIX). A number of additional steps will be required throughout Online Patching, refer to the Section on Privileged Port. Privileged Port (Optional) On a UNIX system the TCP/IP port numbers below 1024 are special in that only processes with root privileges are allowed to listen on those ports. Refer to Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server for additional information on Starting Oracle HTTP Server on a Privileged Port. In Oracle E-Business Suite Release 12.2 additional consideration needs to be given when using a Privileged Port. The following needs to be executed on both the Run and Patch File Systems as the root user. After executing the commands restart HTTP services (by running $ADMIN_SCRIPTS_HOME/adapcctl.sh) on the Run File System. chown root $FMW_HOME/webtier/ohs/bin/.apachectl chmod 6750 $FMW_HOME/webtier/ohs/bin/.apachectl The following additional steps need to be taken during Online Patching when using a privileged port: Before running the prepare phase or the fs_clone phase, you must perform these steps: Ensure that the following commands have been executed as the root user on both the run file system and the patch file system: chown root $FMW_HOME/webtier/ohs/bin/.apachectl chmod 6750 $FMW_HOME/webtier/ohs/bin/.apachectl After running the prepare phase or the fs_clone phase, you must perform these steps: Execute the following commands as the root user on the patch file system: chown root $FMW_HOME/webtier/ohs/bin/.apachectl chmod 6750 $FMW_HOME/webtier/ohs/bin/.apachectl On completion of Online Patching Cutover Phase (adop phase=cutover), Oracle Fusion Middleware Control Console may error when accessing configuration files on the new Run File System. In the event you experience Failed to invoke operation load on MBeanthe opmnctl updatecomponentregistration command should be run. Example command usage: -proxyPort should be set to the Listen directive shown in $FMW_HOME/webtier/instances/{s_ohs_instance}/config/OHS/{s_ohs_component}/admin.conf -oracleInstance should be set to the $FMW_HOME/webtier/instances/{s_ohs_instance} context variable value -componentName should be set to the {s_ohs_component} context variable value $FMW_HOME/webtier/opmn/bin/opmnctl updatecomponentregistration -componentType OHS -proxyPort 10001 -oracleInstance /u01/Z122VIS/fs1/FMW_Home/webtier/instances/EBS_web_Z122VIS_OHS1 -componentName EBS_web_Z122VIS Command requires login to weblogic admin server (<>): Username: weblogic Password: Updating component registration on admin server. Command succeeded. Note: Refer to Oracle E-Business Suite Technology Stack Release Notes for Release 12.2 Document 1376618.1 for additional information. Standard SSL Setup Use Oracle Fusion Middleware Control to make some additional configuration file changes: Login to Oracle Fusion Middleware Control Console (for example http://.:/em) Select Web Tier Target under EBS Domain Select Administration > Advanced Configuration Select ssl.conf file for edit Update the Listen and the VirtualHost _default_: directives to SSL port, for example Listen 4443 Click Apply The following command should be run (on all application tier nodes) to propogate the changes made via 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: 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 SSL 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} {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 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 SSL related variables 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 s_active_webport same as s_webport Verify the port, correct if required. s_webssl_port not applicable Verify the port, correct if required. s_https_listen_parameter not applicable Verify the port, correct if required. s_login_page url constructed with http protocol and s_webport Verify the protocol and port, correct if required. s_external_url url constructed with http protocol and s_webport Verify the protocol and port, correct if required. SSL Offloader Setup Use Oracle Fusion Middleware Control to make some additional configuration file changes: Login to Oracle Fusion Middleware Control Console (for example http://.:/em) Select Web Tier Target under EBS Domain Select Administration > Advanced Configuration Select ssl.conf file for edit Update the ServerName directive to the SSL Offloader . Click Apply Select httpd.conf file for edit Update the ServerName directives to the SSL Offloader . Click Apply Use the Oracle E-Business Suite 12.2 - Oracle Applications Manager (OAM) Context Editor to change the SSL related variables shown in this table: Changes when using an SSL Offloader 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 SSL Offloader external port s_webentryhost same as s_webhost SSL Offloader hostname s_webentrydomain same as s_domainname SSL Offloader 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 Step 11 - Run AutoConfig Run AutoConfig using the adautocfg.sh script in the application tier $ADMIN_SCRIPTS_HOME directory. Step 12 - Customizations (optional) In Oracle E-Business Suite Release 12.2, a Non-SSL port is kept open for those products that need to access some of their pages via the HTTP, and for the Oracle E-Business Suite Help System. If you wish to disable the HTTP port and force all users to access your pages via HTTPS, you can add a redirect rule to the {s_ohs_instance_loc}/config/OHS/{s_ohs_component}/custom.conf file: RewriteCond %{HTTPS} !=on RewriteRule ^/?(.*) https://:/$1 [R,L] Any updates you make to the custom.conf file will be preserved when AutoConfig is run. Step 13 - 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 Section 4 if you wish to test Oracle products that rely on Database Tier Setup being completed. Step 14 - Synchronization between Run and Patch File Systems The following steps need to be performed in order to synchronize the SSL 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 and section after the existing <#Copy Ends> Example commands: #SSL SECTION - START # Required for SSL 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/EBS_domain_%s_dbSid%/opmn/%s_ohs_instance%/%s_ohs_component%/wallet/cwallet.sso %s_other_base%/FMW_Home/user_projects/domains/EBS_domain_%s_dbSid%/opmn/%s_ohs_instance%/%s_ohs_component%/wallet/cwallet.sso rsync -zr %s_current_base%/FMW_Home/user_projects/domains/EBS_domain_%s_dbSid%/opmn/%s_ohs_instance%/wallet/cwallet.sso %s_other_base%/FMW_Home/user_projects/domains/EBS_domain_%s_dbSid%/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: #SSL SECTION - START # Required for SSL 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\EBS_domain_%s_dbSid%\opmn\%s_ohs_instance%\%s_ohs_component%\wallet\cwallet.sso %s_other_base%\FMW_Home\user_projects\domains\EBS_domain_%s_dbSid%\opmn\%s_ohs_instance%\%s_ohs_component%\wallet\cwallet.sso xcopy /ieqy %s_current_base%\FMW_Home\user_projects\domains\EBS_domain_%s_dbSid%\opmn\%s_ohs_instance%\wallet\cwallet.sso %s_other_base%\FMW_Home\user_projects\domains\EBS_domain_%s_dbSid%\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 either the JDK 6/JRockit or JDK 7 copy directive. JDK 6/JRockit Example command: #JDK keystore rsync -zr --include=jdk* --include=jdk*/jre --include=jdk*/jre/lib --include=jdk*/jre/lib/security --include=jrockit* --include=jrockit*/jre --include=jrockit*/jre/lib --include=jrockit*/jre/lib/security --include=cacerts --exclude=* %s_current_base%/FMW_Home/ %s_other_base%/FMW_Home/ #SSL SECTION - END The JDK on AIX and HP is in $COMMON_TOP/util, the following modified JDK keystore command should be used instead of the example previously shown: #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/ #SSL SECTION - END JDK 7 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/ #SSL SECTION - END For JDK 7 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) #SSL SECTION - END Refer to My Oracle Support Knowledge Document 1530033.1 for additional information on JDK 7. 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 SSL setup can then be verified as the Patch File System has now been promoted to be the new Run File System. 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 (which acts as a client sending requests to the Web Server) makes use of 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. When a Load Balancer is being used its certificate(s) will need to be imported into the Database Wallet if a trust point does not already exist, the same goes for when communicating with any external HTTPS Web Server. To enable SSL on the Database Tier you need to only create a wallet, you do not need a separate Server Certificate for this wallet. If you were required to import a Server Certificate (for example ca.crt) and (Intermediate Certificate, for example intca.crt if it exists) into the Application Tier wallet you will need to do it for this wallet also. If communication is required to an external application that is also SSL enabled then you may need to import that applications certificate (to establish the chain of trust). 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. Open the Wallet Manager as a background process: owm & For Windows: The Oracle Wallet Manager can be launched as follows: Start Menu -> All Programs -> Oracle_%SID%_db112_RDBMS -> Integrated Management Tools -> Wallet Manager 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?” 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. 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 SQL>select utl_http.request('

', '', 'file:', null) from dual; where: '

' = the url for your Oracle E-Business Suite Rapid Install Portal. '' = the url of your proxy server, or NULL if not using a proxy server. 'file:' = 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:/d01/R122_EBS/11.2.0/appsutil/wallet', null) from dual; SQL>select utl_http.request('https://www.oracle.com:4443',null, 'file:/d01/R122_EBS/11.2.0/appsutil/wallet', null) from dual; If the wallet has been properly set up, you will be returned the first 2000 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.2 the Web Tier is still managed by OPMN, but Oracle Fusion Middleware WebLogic Server has replaced OC4J used previously. Note: Oracle Fusion Middleware provides a comprehensive security infrastructure detailed in the Security for Oracle Fusion Middleware Documentation Library, including Configuring SSL 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 users browser and the data center. Securing OPMN wallet with Fusion Middleware Control Console is detailed in this document but securing the internal communication (Oracle Weblogic Managed Server and other components with Oracle HTTP Server) will be supported in a later release and detailed in this section when they become available. For additional information on integrating Oracle E-Business Suite Release 12.2 with other Oracle products, refer to the documentation for that product. Section 6: 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.2 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.2 but requires an additional license payment. Note: This configuration is certified for Oracle E-Business Suite Release 12.2 using Forms Listener Servlet (the default mode) on all certified Oracle E-Business Suite Release 12.2 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 Release 12.2 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 ACCEPTED REQUESTED REQUIRED S e r v e r REJECTED OFF OFF OFF No Connection ACCEPTED OFF OFF ON ON REQUESTED OFF ON ON ON REQUIRED No Connection ON ON ON Oracle has certified Oracle E-Business Suite Release 12.2 with the server parameter set to REQUIRED - this ensures that all TNS network traffic is encrypted. Although ANO/ASO supports a number of different encryption algorithms, the supported algorithms are version dependent. For Oracle E-Business Suite Release 12.2 certification, 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 explains how to enable encryption in each of the different ORACLE_HOMEs in an Oracle E-Business Suite deployment. Step 1 - Shut down Application Tier Server Processes and Database Listener On each application tier server, shut down all processes or services: $ $ADMIN_SCRIPTS_HOME/adstpall.sh / On the database server node, shut down the database listener: $ $ORACLE_HOME/appsutil/scripts//addlnctl.sh stop Oracle E-Business Suite Release 12.2 will be unavailable to users until the remaining tasks in this section are completed. Step 2 - Database Tier Changes Log on to the Database Tier server as the file system owner. Source the Database Tier environment file (located in the Oracle Home directory). Take a backup of the $TNS_ADMIN/sqlnet_ifile.ora file. Open the $TNS_ADMIN/sqlnet_ifile.ora file with an editor of your choice and replace the text [crypto seed] with a string consisting of 10 - 70 alphanumeric characters of your choosing. The characters that form the value for this parameter will be used when generating cryptographic keys. SQLNET.ENCRYPTION_TYPES_SERVER=(AES256, AES192, 3DES168) SQLNET.ENCRYPTION_SERVER=REQUIRED SQLNET.CRYPTO_SEED=[crytpo seed] Note: The more random the characters entered into this field are, the stronger the keys will be. Also, to make the resulting key more random and therefore stronger, you should enter as many characters as feasible for the crypto seed. After the changes have been made, restart the listener: $ $ORACLE_HOME/appsutil/scripts//addlnctl.sh start Step 3 - Create $TNS_ADMIN/sqlnet.ora and sqlnet_ifile.ora files on each application tier By default, the Oracle E-Business Suite Release 12.2 application tier installations do not have either a sqlnet.ora or sqlnet_ifile.ora file, so these need to be created. The ANO/ASO directives need to be retained in the sqlnet_ifile.ora file to isolate it from any future AutoConfig updates that affect the sqlnet.ora file. This will need to be done for both the 'run' and 'patch' edition, as fs_clone will not take these files into account if they are only created on the 'run' edition. Log on to the application tier server as the file system owner. Source your application tier environment file (APPS.env), located in the APPL_TOP directory. Navigate to the $TNS_ADMIN directory. Use the editor of your choice to create the sqlnet.ora file, and add the following lines: ############################################################### # #sqlnet.ora file for application tier sqlnet encryption with Advanced SSL Configuration # ############################################################### IFILE = /sqlnet_ifile.ora Use the editor of your 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 SQLNET.CRYPTO_SEED= Note: The SQLNET.CRYPTO_SEED does not need to be the same as the one used on the database tier. Step 4 - Update the Context File Use the Oracle E-Business Suite Release 12.2 - Oracle Applications Manager (OAM) Context Editor to change the SSL related variables on each application tier server, as shown in this table: Advanced SSL Related Variables in the Context File Variable Non-SSL Value Advanced SSL Value s_custom_dbc_params ENCRYPTION_CLIENT=REQUIRED ENCRYPTION_TYPES_CLIENT=(AES256, AES192, 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 5 - 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= Check the AutoConfig log file for errors. Step 6 - Restart the Application Tier Services On each application tier server, restart all processes and services: $ $ADMIN_SCRIPTS_HOME/adstrtal.sh / Appendix A - Using Network Traffic Encryption 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= 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 tracing lines from the SQLNET.ORA file, and restart the TNS Listener. 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, the following message will appear in the SQL*Net trace (.trc) file, but 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 | awk '$5 > 3000 && $5 < 4000' | tail -3 -rw-r--r-- 1 oracle dba 3601 Sep 24 13:57 svr_13815.trc -rw-r--r-- 1 oracle dba 3062 Sep 24 13:58 svr_13817.trc -rw-r--r-- 1 oracle dba 3062 Sep 24 13:59 svr_13819.trc Other files are larger, and will contain "encryption is active, using CRYPTOALGORITHM..." messages. There will be two different algorithms in use, 3DES168 and AES256: $ cd $TNS_ADMIN/trace $ ls -ltr | tail -3 -rw-r--r-- 1 oracle dba 28427064 Sep 24 14:20 svr_11547.trc -rw-r--r-- 1 oracle dba 70609051 Sep 24 14:20 svr_29270.trc -rw-r--r-- 1 oracle dba 763726186 Sep 24 14:20 svr_29144.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 connections via the JDBC interface. Types of Encryption 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, if any, to use 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 RC4_128: RC4 128-bit key RC4_56: RC4 56-bit key RC4_40: RC4 40-bit key Supported 11.x jdbc thin encryption algorithms: 10.2 algorithms above plus: AES256: AES 256-bit key AES192: AES 192-bit key AES128: AES 128-bit key Negotiating Encryption and Integrity 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 ACCEPTED REQUESTED REQUIRED S e r v e r REJECTED OFF OFF OFF Connection fails ACCEPTED OFF OFF ON ON REQUESTED OFF ON ON ON REQUIRED Connection fails ON ON ON Displaying the encryption options available from the Tools and Database ORACLE_HOME. Set your environment to either the Tools or Database ORACLE_HOME, then use the "adapters" command: $ . $ORACLE_HOME/bin/adapters This will display a list of the encryption options available for the following: Installed Oracle Net transport protocols Installed Oracle Net naming methods 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. This would be done on the current 'run' edition. Refer to either the Standard SSL Setup or SSL Offloader Setup sections and revert the changes made to the respective conf files. Run the adSyncContext.pl to sync up the changes (for Standard SSL Setup only). Use the Oracle E-Business Suite 12.2 - Oracle Applications Manager (OAM) Context Editor and change the context variables to the Non-SSL Value noted in the table. Run AutoConfig. Use the adstpall.sh/adstrtal.sh script in the $ADMIN_SCRIPTS_HOME directory to stop and restart all services. If this is change is temporary, there is no need to sync the 'run' and 'patch' edition. Appendix C - Known Issues Issue Description and Workaround Windows: There is a known issue with use of privileged port for SSL. Bug 18341002 Fix is included in the AD/TXK delta 4 consolidated one-off patches R12.AD.C (18491990) and R12.TXK.C (18497540), refer to Note 1617461.1. Change Log Date Description Dec 19, 2014 Added information on SHA2 compatibility and workaround for OWM. Jul 11, 2014 Revised doc to include both doc bug changes as well as comments posted. May 21, 2014 Updated information on optional use of privileged port to match changes to EBS Maintenance Guide - doc bug 17983973 and bug 18502536. May 20, 2014 - Updated Section 3, Step 1 with current AD/TXK patch requirements. - Updated Known Issues for bug 18341002 on Windows. May 15, 2014 - Added Appendix B for steps on disabling SSL - doc bug 18743537. - Added Appendix C for Known Issues. - Corrected some broken links. - Modification to optional privileged port section. - Updated OWM steps to reference use of 2048 bit key size, and added note in the even an MD5 to SHA-1 based CSR is needed. - Modification to Section 6 - doc bug 18360877 - Modification to Section 3, Step 1 - doc bug 17983973 May 9, 2014 Added Windows specific commands within Section 3 Sep 19, 2013 Reviewed and edited in readiness for publication. Oct 13, 2011 Initial creation. My Oracle Support Knowledge Document 1367293.1 by Oracle E-Business Suite Development Copyright © 2011, 2014 Oracle Document Details Rate this documentEmail link to this documentOpen document in new windowPrintable Page Type: Status: Last Major Update: Last Update: Language: WHITE PAPER PUBLISHED 20-Dec-2014 20-Dec-2014 Related Products Oracle Applications Technology Stack Information Centers Information Center: E-Business Suite Utilities (Cloning, Autoconfig, Patching) [1375925.2] Information Center: Patching E-Business Suite Utilities (AD, Clone, Autoconfig) [1377810.2] Information Center: Troubleshooting E-Business Suite Utilities [1377828.2] Information Center: Overview EBS Technology Stack OID and SSO and OAM [1461465.2] Information Center: Using EBS Technology Stack Java [1462269.2] Show More Document References No References available for this document. Recently Viewed Oracle E-Business Suite Release 12.2 Information Center [1581299.1] E1: MOB Login Failed Error On Mobile Application - Certificate chain received from (MachineName) - XX.XXX.XX.XX was not trusted causing SSL handshake failure. [1484689.1] Procedure of HowTo to disable SSLv3 on Oracle Communications EAGLE EPAP 15.0.x [1945734.1] Oracle Solaris Studio IPS Installation Fails with "Framework Error: Code: 7" [1485299.1] How to Interpret, Understand and Resolve Common pkg(1) Errors on Solaris 11 [1574718.1] Show More Attachments GIFWalletMgr.GIF(113.35 KB)