FORSMILE
JA
セキュリティ2026/09/07

Oracle HTTP Server and WebLogic Proxy Plug-in: Component and Patch Checklist

Inventory the web tier separately from WebLogic Server. Record Oracle Home patch history, the configured plug-in path and post-change checks in a handoff template.

← Back to Blog

An updated WebLogic Server does not establish that its front-end plug-in was updated. Trace each service from its entry point and record the components on each host. This checklist helps administrators hand over evidence; it is not a universal patch installation procedure.

Oracle public documentation was checked on September 7, 2026. The OPatch examples use the Fusion Middleware 12.2.1.4 documentation. For other releases, including 14c, consult the matching guide and the downloaded patch README. Commands and patch installation have not been tested in a running Oracle environment.

1. Map the request path

  • ▸Entry web server: identify OHS, Apache HTTP Server or IIS for each host.
  • ▸Proxy component: distinguish an OHS-bundled component from a separately installed WebLogic Server Proxy Plug-in. Check the configured file and installation records.
  • ▸Backend: record the WebLogic host, domain and owner. The web tier may have a different owner.
  • ▸Coverage: include standby nodes and old environments. Mark each as active, stopped or unknown, and assign verification before any stopped environment is reused.

Oracle's 14.1.2 overview distinguishes the OHS-bundled plug-in from the Apache ZIP distribution. The Apache configuration examples use LoadModule and mod_wl_24.so: inspect the referenced file, not just an extracted directory. For IIS, use that release's documentation and deployment records instead of Apache configuration names.

2. Capture history for each Oracle Home

For an OPatch-managed Oracle Home, run version and lsinventory from that Home's OPatch. These Linux/UNIX shell examples require ORACLE_HOME to identify the intended absolute path. They inspect rather than apply patches, but create log files.

sh
# Linux / UNIX: use the Oracle Home you intend to inspect
"$ORACLE_HOME/OPatch/opatch" version
"$ORACLE_HOME/OPatch/opatch" lsinventory

On Windows, use opatch.bat in the target Home's OPatch directory. These examples use Command Prompt, not PowerShell. Check the Oracle Home shown in the output before accepting the result.

bat
REM Windows Command Prompt: ORACLE_HOME must identify the target home
"%ORACLE_HOME%\OPatch\opatch.bat" version
"%ORACLE_HOME%\OPatch\opatch.bat" lsinventory
  • ✓Record Oracle Home, OPatch version, execution time and log location.
  • ✓Record the product, applied patch IDs and dates, and map them to the patch README.
  • ✓Inspect other Homes and nodes separately.
  • ✓Mark failed checks as unknown; an error is not evidence of no patches or no installed product.

For a separately extracted plug-in, another Oracle Home's inventory is insufficient. Collect distribution identifiers, replacement records and the configured path. Ask the maintainer where evidence is missing instead of guessing the version.

3. Match the remediation requirement and verify the change

Map recorded patch IDs to the relevant Oracle advisory and My Oracle Support patch documentation. A base version alone is insufficient. If a later patch includes the fix, retain evidence for its applicability and inclusion. This article has not checked authenticated, patch-specific README files or patch IDs.

  • ✓Before work: agree the target Home, plug-in and nodes, README requirements, downtime, backup and recovery plan.
  • ✓After work: retain logs and inventory; record completion of required restarts and additional steps.
  • ✓Configuration: verify the configured plug-in path points to the updated file.
  • ✓Service: execute agreed connectivity, authentication, key-page and backend checks, recording times and results.
  • ✓Follow-up: investigate errors or suspicious activity separately. A page loading successfully proves neither remediation nor absence of compromise.

4. Handoff template

This editorial template is for one component and node at a time. Give every unknown an owner and deadline. Keep configuration and logs in your approved internal repository.

text
Checked at / checked by:
Service / environment (production, standby, test):
Host / node:
Entry web server and version:
Plug-in type / version / distribution identifier:
Oracle Home or plug-in directory:
Configured plug-in path:
WebLogic backend / responsible team:
Advisory / patch README:
OPatch version / patch IDs / application dates:
Evidence of fix inclusion in a later patch, if applicable:
Before-and-after inventory and log location:
Shutdown / restart / additional steps completed:
Connectivity / authentication / key-page results:
Status (verified, pending action, unknown, not applicable):
Evidence supporting the status:
Open items / owner / deadline:

Not applicable also needs evidence. If records are missing, use unknown. Completion means operations can provide the evidence and the security owner can assess it against the remediation requirement.

Related articles