10 Oracle Web Cache

10.1.1 Reset the Random Password Generated in the Oracle Portal, Forms, Reports and Discoverer Install Types

For enhanced security, no default hard-coded passwords are used for managing Oracle Web Cache.

When you install the Oracle Web Tier installation type, the Oracle Universal Installer prompts you to choose a password. The Web Cache Administrator page of the Oracle Universal Installer prompts you to enter a password for the administrator account. The administrator account is the Oracle Web Cache administrator authorized to log in to Oracle Web Cache Manager and make configuration changes through that interface.

When you install the Oracle Portal, Forms, Reports and Discoverer installation type, the prompt for the administrator password is missing. Instead, the Oracle Portal, Forms, Reports and Discoverer install type uses a random value chosen at install time.

No matter the installation type, before you begin configuration, change the passwords for these accounts to a secure password. If you are configuring a cache cluster, all members of the cluster must use the same password for the administrator account.

To change the password, use the Passwords page of Fusion Middleware Control, as described in Section 5.2, "Configuring Password Security," of the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

10.1.2 Running Oracle Web Cache Processes as a Different User Is Not Supported

Running Oracle Web Cache as a user other than the installed user through the use of the webcache_setuser.sh setidentity command is not supported for this release. Specifically, you cannot change the user ID with the following sequence:

1. Change the process identity of the Oracle Web Cache processes in the Process Identity page using Oracle Web Cache Manager (Properties > Process Identity).

2. Use the webcache_setuser.sh script as follows to change file and directory ownership:

   webcache_setuser.sh setidentity <user_ID> 
   

   where <user_ID> is the user you specified in the User ID field of the Process Identity page.

3. Restart Oracle Web Cache using opmnctl.

   Oracle Web Cache will start and then immediately shut down.

   In addition, messages similar to the following appear in the event log:

   [2009-06-02T21:22:46+00:00] [webcache] [ERROR:1] [WXE-13212] [logging] [ecid: ] Access log file /scratch/webtier/home/instances/instance1/diagnostics/logs/WebCache/webcache1/access_log could not be opened.
   [2009-06-02T21:22:46+00:00] [webcache] [WARNING:1] [WXE-13310] [io] [ecid: ] Problem opening file /scratch/webtier/home/instances/instance1/config/WebCache/webcache1/webcache.pid (Access Denied).
   [2009-06-02T21:22:46+00:00] [webcache] [ERROR:1] [WXE-11985] [esi] [ecid: ] Oracle Web Cache is unable to obtain the size of the default ESI fragment page /scratch/webtier/home/instances/instance1/config/WebCache/webcache1/files/esi_fragment_error.txt.
   [2009-06-02T21:22:46+00:00] [webcache] [WARNING:1] [WXE-11905] [security] [ecid: ] SSL additional information: The system could not open the specified file.
   

For further information about the webcache_setuser.sh script, see Section 5.9, "Running webcached with Root Privilege," of the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

10.1.3 Certificate Revocation Lists (CRLs)

Fusion Middleware Control or Oracle Web Cache Manager do not provide support for client certificate validation with Certificate Revocation Lists (CRLs). You can configure this support by manually editing the webcache.xml file.

Client certificate revocation status is checked against CRLs that are located in a file system directory. Typically, CRL definitions are valid for a few days, and must be updated on a regular basis. Whenever the CRL definitions are modified, you must restart Oracle Web Cache.

When CRL validation is enabled and available, Oracle Web Cache performs certificate revocation status checking for client certificates. The SSL connection is rejected if a certificate is revoked. SSL connections are accepted if no CRL is found, or if the certificate has not been revoked.

To configure certificate validation with CRL

1. Enable client certificate for the HTTPS listen port. See Section 5.5.2, "Requiring Client-Side Certificates," of the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

2. Use a text editor to open webcache.xml, located in:

   (UNIX) ORACLE_INSTANCE/<instance_name>/config/WebCache/<webcache_name>
   (Windows) ORACLE_INSTANCE\<instance_name>\config\WebCache\<webcache_name>
   

3. Locate the HTTPS listen port in webcache.xml for which CRL checking needs to be enabled, and add the SSLCRLENABLE="YES" parameter to the LISTEN directive. For example:

   ...
   <LISTEN IPADDR="ANY" PORT="443" PORTTYPE="NORM" SSLENABLED="SSLV3_V2H"  CLIENT_CERT="YES" SSLCRLENABLE="YES" STRONG_CRYPTO_ONLY="NO" Key="IPADDR PORT">
   ...
   

4. Configure CRL file or location by adding the SSLCRLPATH and SSLCRLFILE parameters to the HTTPS LISTEN directive.

   • SSLCRLPATH: Enter the path to the directory where CRLs are stored. Ensure that the path is correct; otherwise CRL checking will not work. This parameter has no default value.

   • SSLCRLFILE: Enter the path to a comprehensive CRL file where PEM-encoded (BASE64 CRLs are concatenated in order of preference in one file. If this parameter is set, then the file must be present at the specified location. Otherwise CRL checking will not work.

   For example:

   ...
   <LISTEN IPADDR="ANY" PORT="443" PORTTYPE="NORM" SSLENABLED="SSLV3_V2H"  CLIENT_CERT="YES" SSLCRLENABLE="YES"  SSLCRLFILE="/ORACLE_HOME/webcache/crls/sample_crl" SSLCRLPATH="/ORACLE_HOME/webcache/crls/" STRONG_CRYPTO_ONLY="NO" Key="IPADDR PORT">
   ...
   

   Use the command line utility orapki to rename CRLs in your file system. See the section titled "Certificate Revocation List Management" in the Oracle Database Advanced Security Administrator's Guide from the Oracle Database documentation library for information about using orapki.

5. Save webcache.xml.

6. Restart Oracle Web Cache with the following command:

   opmnctl restartproc ias-component=component_name
   

   This executable is found in the following directory:

   (UNIX) ORACLE_INSTANCE/bin
   (Windows) ORACLE_INSTANCE\bin
   

   In a cluster configuration, when configuration changes are made directly to a cluster member's webcache.xml file, use Fusion Middleware Control or Oracle Web Cache Manager to propagate the change to other cluster members. See Section 3.6, "Configuring a Cache Cluster for Caches Using the Same Oracle WebLogic Server," or Section 3.7, "Configuring a Cache Cluster for Unassociated Caches or Caches Using Different Oracle WebLogic Servers," of the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

10.1.4 Defining Duplicate Origin Servers Causes Startup Failure

Fusion Middleware Control enables you to configure multiple origin servers using the same host name and port number. Configure origin servers with duplicate host and port settings, both the cache server and admin server processes fail to start.

To resolve this issue:

1. Use a text editor to open webcache.xml, located in:

   (UNIX) ORACLE_INSTANCE/<instance_name>/config/WebCache/<webcache_name>
   (Windows) ORACLE_INSTANCE\<instance_name>\config\WebCache\<webcache_name>
   

2. Find the two or more HOST elements with the same NAME and PORT values as mentioned in the startup error message in the event log. Edit the port number of one of the HOST elements so that it is a unique value between 1 and 65535.

   For example, suppose the error message in the event log is as follows:

   Duplicate origin server hosts specified for host my.company.com port 8888.
   

   Also, the HOST elements in webcache.xml are as follows:

   <HOST OSSTATE="ON" LOADLIMIT="100" PORT="8888" NAME="my.company.com" ID="h1" />
     <HOST OSSTATE="ON" LOADLIMIT="100" PORT="8888" NAME="my.company.com" ID="h2" />
   

   You would modify the PORT value for one. For example:

   <HOST OSSTATE="ON" LOADLIMIT="100" PORT="8888" NAME="my.company.com" ID="h1" />
     <HOST OSSTATE="ON" LOADLIMIT="100" PORT="9999" NAME="my.company.com" ID="h2" />
   

You can now restart the admin and cache server processes. You can then use Fusion Middleware Control or Web Cache Manager to make further configuration changes.

For further information about the configuring site-to-server mapping, see Section 2.11.2, "Specify Origin Server Settings" of the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

10.1.5 Mixed Protocols in Site-to-Server Mappings Causes Startup Failures

When you map sites to origin servers you cannot create a mapping that has a mix of HTTP and HTTPS origin sever. Select origin servers using HTTP or HTTPS, but not both protocols. If you select of origin server using a mix of HTTP and HTTP, both the cache server and admin server processes fail to start.

To resolve this issue:

1. Use a text editor to open webcache.xml, located in:

   (UNIX) ORACLE_INSTANCE/<instance_name>/config/WebCache/<webcache_name>
   (Windows) ORACLE_INSTANCE\<instance_name>\config\WebCache\<webcache_name>
   

2. And the VIRTUALHOSTMAP element:

   <VIRTUALHOSTMAP PORT="80" NAME="my.company.com">
     <HOSTREF HOSTID="h1"/>
     <HOSTREF HOSTID="h2"/>
   </VIRTUALHOSTMAP>
   

3. Remove one of the HOSTREF child elements. For example:

   <VIRTUALHOSTMAP PORT="80" NAME="my.company.com">
     <HOSTREF HOSTID="h1"/>
    </VIRTUALHOSTMAP>
   

You can now restart the admin and cache server processes. You can also use Fusion Middleware Control or Oracle Web Cache Manager to make further configuration changes.

For further information about the configuring site-to-server mapping, see Section 2.11.4, "Map Site Definitions to Origin Servers," of the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.