One of the major concerns that we had while upgrading Oracle EBS R12 version from 12.2.10 to 12.2.14 was how to bring the Oracle ORDS instance under the same SSL hood as we didn’t have a plan to have another server dedicated for ORDS. Our current setup is like below, single instance of Oracle EBS R12 12.2.14 SSL enabled and the ORDS instance hosted from the same server using Apache-Tomcat, that listens to default 8080 port.
The business requirement is pretty straight forward. Develop using APEX, access it from the EBS environment, doesn’t mean we are not going to have standalone APEX applications as extensions for EBS.
Now, comes the real issue. How to bring both instances to the same SSL hood? For example, EBS instance is accessed from the URL https://hostname & we must ensure that the ORDS instance also should be accessible from the same hostname like https://hostname/ords
Please note, none of the below hacks are advisable for a PRODUCT environment. While the hack perfectly fits the TESTING environments, the resources for EBS could be severely compromised when the APEX instance becomes hungry for more resources in the form of processing and memory. Follow the Oracle recommendations always for hosting ORDS from a different server. I will post comprehensive suggestions compiled by AI by the end of this post. This hack was tested against an instance of Oracle EBS R12 12.2.14 & should work with R12 12.2.x versions. Point to interest, version 12.2.14 is the initial version of R12 that tightly integrates APEX, hence do not expect your applications start enjoying the same fruits, if you are on a previous release. Regardless, the reverse proxy method should work.
Let us hack
As application manager user, shutdown the application instance and run the below command
grep "ssl.conf" $FND_TOP/admin/driver/fndtmpl.drv
This should provide you an output like the below
fnd admin/template oracle_apache_ssl_conf_FMW.tmp INSTE8 <s_ohs_instance_loc>/config/OHS/<s_ohs_component> oracle_apache_ssl.conf 600
Once we have the template name, for this case, “oracle_apache_ssl_conf_FMW.tmp”, we should copy this template to $FND_TOP/admin/template/custom folder. If there is no custom folder, create one. Please note, “custom” is the only allowed name and case sensitive. Always read the header area of the template, that will help you to understand whether the template will be merged during the next autoconfig run.
cp $FND_TOP/admin/template/oracle_apache_ssl_conf_FMW.tmp $FND_TOP/admin/template/custom/oracle_apache_ssl_conf_FMW.tmp
Using your favorite text editor, open up the template file from custom folder and add the following entries by the dead end of the file
<IfModule mod_proxy.c> ProxyRequests Off ProxyPreserveHost On ProxyPass /ords http://fullyqualifieddomainname:8080/ords ProxyPassReverse /ords http://fullyqualifieddomainname:8080/ords ProxyPass /i http://fullyqualifieddomainname:8080/i ProxyPassReverse /i http://fullyqualifieddomainname:8080/i <Location /ords> RequestHeader set X-Forwarded-Proto "https" RequestHeader set X-Forwarded-Port "443" </Location></IfModule>
Here the fully qualified domain name should be replaced with your hostname, for example “apps.example.com”
Now run the below commands
$ADMIN_SCRIPTS_HOME/adadminsrvctl.sh startperl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE
It’s time to run “autoconfig“. Please make sure that all the above exercises were performed on the run file edition environment.
Once the autoconfig completes “successfully”, quickly ensure the OHS instance has the “oracle_apache_ssl.conf” file amended with custom template entries.
grep "ProxyPass /ords" $FMW_HOME/webtier/instances/*/config/OHS/*/oracle_apache_ssl.conf
If you see a result like the below
ProxyPass /ords http://fullyqualifieddomainname:8080/ords
That means your custom template was merged and you can proceed to next configuration modification. This time we will be making a change to Apache-Tomcat web server. Switch to your Apache-tomcat installation folder, for example ‘/u01/apache-tomcat/conf’, make a backup for the file server.xml. Now, edit the server.xml file and replace the block that looks like this
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
with the below
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" proxyName="fullyqualifieddomainname" proxyPort="443" scheme="https" secure="true" SSLEnabled="false" URIEncoding="UTF-8" />
Save the configuration file. Start EBS application tier and Apache-Tomcat server sequentially. You should able to access your ORDS instance by calling https://hostname/ords now. In addition you may able to make these entries using enterprise manager OHS plug-ins.
By bringing the ORDS instance under the same SSL hood, you are going to avoid multiple access issues, one of them being the “mixed content” error when the EBS tries to access the APEX applications using ORDS that is HTTP. Although this hack is to survive future autoconfig and patching cycles, NOT AT ALL recommended.
Please consider the suggestions compiled by one of the major AI agents, as listed below.
Prompt
Currently we are hosting both ORACLE EBS R12 and APEX under the same hostname. Can you find Oracle’s recommendations for independent hosts for each product? Further help me to understand the implication incase if we continue with the current setup, achieved by modifying ssl.conf using template for reverse proxy. Maximize your explanations, recommendations and assessment.
AI response
Oracle’s official guidance on deploying E-Business Suite (EBS R12) and Oracle Application Express (APEX) emphasizes separation of concerns in architecture. Let’s break this down into recommendations, implications, and strategic assessment.
🔹 Oracle’s Recommendations
- Independent Middle Tiers: Oracle recommends deploying APEX and EBS on separate middle-tier hosts.
- EBS R12 relies on Oracle WebLogic + Forms/Servlets stack.
- APEX runs on Oracle REST Data Services (ORDS), typically deployed on a standalone WebLogic, Tomcat, or Oracle HTTP Server.
- Reverse Proxy Usage: Oracle supports reverse proxying (via Oracle HTTP Server or Apache) but recommends distinct hostnames or subdomains (e.g.,
ebs.company.comvs.apex.company.com) for clarity, isolation, and SSL management. - Security & Maintainability: Oracle’s technical papers highlight that mixing workloads under one hostname complicates SSL termination, cookie/session management, and audit compliance.
🔹 Implications of Current Setup (Same Hostname via ssl.conf Reverse Proxy)
| Area | Risk/Implication |
|---|---|
| Security | Shared hostname increases risk of cross-application cookie leakage, session hijacking, and difficulty in applying distinct SSL/TLS policies. |
| Audit & Compliance | Regulatory audits (SOX, GDPR, VAT compliance) often require clear segregation of application boundaries. Mixing under one hostname weakens traceability. |
| Operational Complexity | Reverse proxy rules in ssl.conf must be carefully maintained. Any misconfiguration can expose APEX apps through EBS paths or vice versa. |
| Performance | Both stacks compete for network and SSL termination resources. Troubleshooting latency or bottlenecks becomes harder. |
| Patching & Upgrades | EBS patches (WebLogic, Forms) and APEX/ORDS upgrades have different cycles. Sharing a hostname risks downtime overlap and dependency conflicts. |
| Disaster Recovery | Hostname-level coupling complicates failover. Independent hosts allow selective DR strategies (e.g., APEX-only failover without impacting EBS). |
🔹 Strategic Assessment & Recommendations
- Move Toward Independent Hosts
- Assign separate DNS names and SSL certificates.
- Example:
ebs.company.com→ EBS R12 stack;apex.company.com→ ORDS/APEX stack. - This aligns with Oracle’s recommended middle-tier deployment architecture.
- If You Continue Current Setup
- Harden reverse proxy rules: ensure strict path-based routing (
/apex/*vs/OA_HTML/*). - Isolate cookies: configure
SameSite,Secure, andHttpOnlyflags to prevent leakage. - Maintain separate SSL contexts within
ssl.conffor each app. - Document routing logic for audit purposes.
- Harden reverse proxy rules: ensure strict path-based routing (
- Future-Proofing
- Independent hosts simplify cloud migration (OCI, AWS).
- Easier to scale APEX independently (APEX often grows faster with custom apps).
- Supports hybrid DR strategies and microservices-style extension of EBS.
🔹 My Assessment
Continuing with the same hostname setup is technically feasible but audit-unfriendly, harder to maintain, and risk-prone. Oracle’s stance is clear: separate middle tiers and hostnames provide cleaner architecture, stronger compliance, and operational resilience.
















