1. Administering Oracle HTTP Server
  2. Managing Oracle HTTP Server
  3. Running Oracle HTTP Server

4 Running Oracle HTTP Server

To run Oracle HTTP Server, create and manage an Oracle HTTP Server instance in a WebLogic or standalone environment.

This chapter describes how to create an instance, perform basic Oracle HTTP Server tasks, and remotely administer Oracle HTTP Server. It includes the following sections:

  • Before You Begin
    Before running Oracle HTTP Server, there are prerequisite tasks that are to be completed. These tasks include installing and configuring the server, and starting WebLogic Server and Node Manager.
  • Creating an Oracle HTTP Server Instance
    The Configuration Wizard enables you to simultaneously create multiple Oracle HTTP Server instances when you create a domain.
  • Performing Basic Oracle HTTP Server Tasks
    You can use WLST or Fusion Middleware Control to perform basic Oracle HTTP Server administration tasks.
  • Remotely Administering Oracle HTTP Server
    You can remotely manage an Oracle HTTP Server instance running in a standalone environment from a collocated Oracle HTTP Server implementation running on a separate machine. Use WLST or Fusion Middleware Control to start, stop, and configure the server from the remote machine.
  • Configuring SSL for Admin Port
    Admin port is used internally by Oracle HTTP Server (OHS) to communicate with the OHS plugin for Node Manager. The OHS plugin for Node Manager has been enhanced to use SSL for its communication with the Node Manager.

Parent topic: Managing Oracle HTTP Server

Before You Begin

Before running Oracle HTTP Server, there are prerequisite tasks that are to be completed. These tasks include installing and configuring the server, and starting WebLogic Server and Node Manager.

  1. Install and configure Oracle HTTP Server as described in Installing and Configuring Oracle HTTP Server.
  2. SSL is enabled by default on Oracle HTTP Server admin host. The admin host of the newly created instance is configured to use the default wallet which has a self-signed certificate. You must change the admin host after configuration to use a CA-signed certificate for security reasons using the instructions described in "Configuring SSL for Admin Host".
  3. If you run Oracle HTTP Server in a WebLogic Server Domain, start WebLogic Server as described in Starting and Stopping Servers in Administering Server Startup and Shutdown for Oracle WebLogic Server.

    Note:

    • When you start WebLogic Server from the command line, you might see many warning messages. Despite these messages, WebLogic Server should start normally.

    • On the Windows platform, Oracle HTTP Server requires Microsoft Visual C++ run-time libraries to be installed on the system to function. See Installing and Configuring Oracle HTTP Server.

  4. Start Node Manager (required for both WebLogic and standalone domains) as described in Using Node Manager in Administering Node Manager for Oracle WebLogic Server.

Parent topic: Running Oracle HTTP Server

Creating an Oracle HTTP Server Instance

The Configuration Wizard enables you to simultaneously create multiple Oracle HTTP Server instances when you create a domain.

If you are creating a WebLogic Server Domain (Full or Restricted JRF domain types), you are not required to create any instances. If you elect not to create any instances, a warning appears; however, you are allowed to proceed with the configuration process.

If you are creating a standalone domain, an Oracle HTTP Server instance is created by default.

This section contains the following information:

Note:

If you are attempting to create an Oracle HTTP Server instance that uses a TCP port in the reserved range (typically less than 1024), then you must perform some extra configuration to allow the server to bind to privileged ports. See Starting Oracle HTTP Server Instances on a Privileged Port (UNIX Only).

Parent topic: Running Oracle HTTP Server

Creating an Oracle HTTP Server Instance in a WebLogic Server Domain

You can create a managed Oracle HTTP Server instance in a WebLogic Server Domain by using either the WLST custom command ohs_createInstance() or from Fusion Middleware Control installed as part of a Oracle Fusion Middleware infrastructure. The following sections describe these procedures.

Note:

If you are working with a WebLogic Server Domain, it is recommended to use the Oracle HTTP Server WLST custom commands as described in Administering Oracle HTTP Server Using WLST. These commands offer superior error checking, provide automatic port management, and so on.

Parent topic: Creating an Oracle HTTP Server Instance

Creating an Instance by Using WLST

You can create an Oracle HTTP Server instance in a WebLogic Server Domain by using WLST. Follow these steps.

  1. From the command line, launch WLST.

    Linux or UNIX: $ORACLE_HOME/oracle_common/common/bin/wlst.sh

    Windows: $ORACLE_HOME\oracle_common\common\bin\wlst.cmd

  2. Connect to WLST:

    • In a WebLogic Server Domain:

      > connect('loginID', 'password', '<adminHost>:<adminPort>')

      For example:

      > connect('weblogic', '<yourpassword>', 'abc03lll.myCo.com:7001')
  3. Use the ohs_createInstance() command, with an instance and machine name—which was assigned during domain creation—to create the instance:
    > ohs_createInstance(instanceName='ohs1', machine='abc03lll.myCo.com', [listenPort=XXXX], [sslPort=XXXX], [adminPort=XXXX])

    Note:

    If Node Manager is down, the create command takes place partially. The master copy of the config files appear at OHS/componentName. Once Node Manager comes back up, the system syncs again and the runtime copy of the files appear at OHS/instances/componentName.

    For example:

    > ohs_createInstance(instanceName='ohs1', machine='abc03lll.myCo.com')

    Note:

    If you do not provide port numbers, they will be assigned automatically.

Note:

For information about using the WebLogic Scripting Tool (WLST), see Understanding the WebLogic Scripting Tool.

Associating Oracle HTTP Server Instances With a Keystore Using WLST

After using the Configuration Wizard to create Oracle HTTP Server instances in collocated mode, use the ohs_updateInstances WLST custom command to associate the instances with a keystore.

This command parse across all of the Oracle HTTP Server instances in the domain and perform the following tasks:

  • Create a new keystore with the name <instanceName>_default if one does not exist.

  • Put a demonstration certificate, demoCASignedCertificate in the newly created keystore.

  • Export the keystore to the instance location.

See ohs_updateInstances.

To associate Oracle HTTP Server instances with a keystore:

  1. Launch WLST from the command line.

    Linux or UNIX: $ORACLE_HOME/oracle_common/common/bin/wlst.sh

    Windows: $ORACLE_HOME\oracle_common\common\bin\wlst.cmd

  2. Connect to the Administration Server instance:
    connect('<userName', '<password>', '<host>:<port>')
  3. Issue the ohs_updateInstances WLST custom command, for example: 
    ohs_updateInstances()
Creating an Instance by Using Fusion Middleware Control

You can create an Oracle HTTP Server instance in a WebLogic Server Domain by using Fusion Middleware Control installed as part of the Oracle Fusion Middleware infrastructure. Follow these steps.

  1. Log in to Fusion Middleware Control and navigate to the system component instance home page for the WebLogic Server Domain within which you want to create the Oracle HTTP Server instance.
  2. Open the WebLogic Server Domain menu and select Administration then Create/Delete OHS.

    Note:

    Create/Delete OHS will appear only if you have extended the domain by using the Oracle HTTP Server domain template. Otherwise, this command will not be available.

    The OHS Instances page appears.

  3. Click Create.

    The Create OHS Instance page appears.

  4. In Instance Name, enter a unique name for the Oracle HTTP Server instance; for example, ohs_2.
  5. In Machine Name, click the drop-down control and select the machine to which you want to associate the instance.
  6. Click OK.

    The OHS Instance page reappears, showing a confirmation message and the new instance. The port number is automatically assigned.

After creating the instance, the Column on the OHS Instances page shows a down-arrow for that instance.

This indicates that the instance is not running. For instructions on starting an instance, see Starting Oracle HTTP Server Instances. Once started, the arrow will point up.

About Instance Provisioning

Once an instance is created, it will be provisioned within the DOMAIN_HOME.

  • The master (staging) copy will be in:

    DOMAIN_HOME/config/fmwconfig/components/OHS/componentName

  • The runtime will be in:

    DOMAIN_HOME/config/fmwconfig/components/OHS/instances/componentName

    Node Manager must be running to provision an instance in runtime.

Immediately after creation, the state reported for an Oracle HTTP Server instance will vary depending on how the instance was created:

  • If ohs_createInstance() was used, the reported state for the instance will be SHUTDOWN.

  • If the Configuration Wizard was used, the reported state for the instance will be UNKNOWN.

Creating an Oracle HTTP Server Instance in a Standalone Domain

If you select Standalone as your domain during server configuration, the Configuration Wizard will create the domain, and during this process an Oracle HTTP Server instance will also be created. See Installing and Configuring Oracle HTTP Server.

Parent topic: Creating an Oracle HTTP Server Instance

Performing Basic Oracle HTTP Server Tasks

You can use WLST or Fusion Middleware Control to perform basic Oracle HTTP Server administration tasks.

For detailed information on the process ID (PID) file, and how to use WLST or Fusion Middleware Control to perform basic administration tasks, see the following tasks:

Parent topic: Running Oracle HTTP Server

Understanding the PID File

The process ID can be used by the administrator when restarting and terminating the daemon. If a process stops abnormally, it is necessary to stop the httpd child processes using the kill command. You must not change the default PID file name or its location.

When Oracle HTTP Server starts, it writes the process ID (PID) of the parent httpd process to the httpd.pid file located in the following directory: 

DOMAIN_HOME/servers/<componentName>/logs

The PidFile directive in httpd.conf specifies the location of the PID file; however, you should never modify the value of this directive.

See Also:

PidFile directive in the Apache HTTP Server documentation.

Parent topic: Performing Basic Oracle HTTP Server Tasks

Starting Oracle HTTP Server Instances

This section contains information on how to start Oracle HTTP Server using Fusion Middleware Control and WLST.

Note:

On the Windows platform, Oracle HTTP Server requires Microsoft Visual C++ run-time libraries to be installed on the system to function. See Installing and Configuring Oracle HTTP Server.

This section includes the following topics:

Parent topic: Performing Basic Oracle HTTP Server Tasks

Starting Oracle HTTP Server Instances Using Fusion Middleware Control

In Fusion Middleware Control, you start the Oracle HTTP Server from the Oracle HTTP Server home page. Navigate to the HTTP Server home page and do one of the following:

  • From the Oracle HTTP Server menu:

    1. Select Control.

    2. Select Start Up from the Control menu.

  • From the Target Navigation tree:

    1. Right-click the Oracle HTTP Server instance you want to start.

    2. Select Control.

    3. Select Start Up from the Control menu.

  • From the page header, select Start Up.

    The instance will start in the state UNKNOWN.

Starting Oracle HTTP Server Instances Using WLST

To start an Oracle HTTP Server instance by using WLST, use the start() command in a WebLogic Server Domain or nmStart() for a standalone domain. The commands are illustrated in the following table.

Note:

  • Node Manager must be running for these commands to work. If it is down, you will receive an error message.

  • serverType is required for standalone domains. If it is not included an error will be thrown referencing an inability to find startWebLogic.

These commands assume you have created an Oracle HTTP Server instance, as described in Creating an Oracle HTTP Server Instance and WLST is running.

Domain Syntax Example

WebLogic

 
start('instanceName')

or

nmStart(serverName='name', serverType='type')
 
start('ohs1')

or

nmStart(serverName='ohs1', serverType='OHS')

Standalone

 
nmStart(serverName='name', serverType='type')
 
nmStart(serverName='ohs1', serverType='OHS')
Starting Oracle HTTP Server Instances from the Command Line

You can start Oracle HTTP Server instances from the command line by invoking the startComponent script from the host that contains the Administration Server.

  1. Ensure that Node Manager is running.
  2. Enter the following command:

    Linux or UNIX: $DOMAIN_HOME/bin/startComponent.sh componentName

    Windows: DOMAIN_HOME\bin\startComponent.cmd componentName

    For example:

    $DOMAIN_HOME/bin/startComponent.sh ohs1

    The startComponent script contacts Node Manager and runs the nmStart() command.

  3. When prompted, enter your Node Manager password. The system responds with these messages:
    Successfully started server componentName...
Successfully disconnected from Node Manager...

Exiting WebLogic Scripting Tool.

Note:

You can also use this script to start Oracle HTTP Server instances remotely. In that case, the scripts read the configuration to determine the location of the component. You must run this script from the same system as the Administration Server. See Remotely Administering Oracle HTTP Server.
Storing Your Node Manager Password

You can avoid having to enter your Node Manager password every time you launch the server with startComponent command by starting it with the storeUserConfig option for the first time. Do the following:

  1. At the prompt, enter the following command:
    $DOMAIN_HOME/bin/startComponent.sh componentName storeUserConfig

    The system will prompt for your Node Manager password.

  2. Enter your password.

    The system responds with this message:

    Creating the key file can reduce the security of your system if it is not kept
in a secured location after it is created. Creating new key...
The username and password that were used for this WebLogic NodeManager
connection are stored in $HOME/.wlst/nm-cfg-myDomainName.props and 
$HOME /.wlst/nm-key-myDomainName.props.
Starting Oracle HTTP Server Instances on a Privileged Port (UNIX Only)

WARNING:

When this procedure is completed, any Oracle HTTP Server processes running from this Oracle Home will be able to bind to privileged ports.

On a UNIX system, TCP ports in a reserved range (typically less than 1024) can only be bound by processes with root privilege. Oracle HTTP Server always runs as a non-root user; that is, the user who installed Oracle Fusion Middleware. On UNIX, special configuration is required to allow Oracle HTTP Server to bind to privileged ports.

To enable Oracle HTTP Server to listen on a port in the reserved range (for example, the default port 80 or port 443) use the following one-time setup on each Oracle HTTP Server machine:

  1. Update the ORACLE_HOME/ohs/bin/launch file by performing the following steps as the super user (if you do not have access to super user privileges, have your system administrator perform these steps):

    1. Change ownership of the file to root:

      chown root $ORACLE_HOME/ohs/bin/launch

    2. Change the permissions on the file as follows:

      chmod 4750 $ORACLE_HOME/ohs/bin/launch

      The steps that require root permissions are now complete.

    3. Modify the port settings for Oracle HTTP Server as described in Managing Ports.

  2. Configure the User and Group directive in httpd.conf.

    The configured user ID for User should be the same user ID that created the instance. The configured group ID for Group must be the same group ID used to create the instance. See Oracle HTTP Server Configuration Files. To configure Oracle HTTP Server to run as a different user id see Starting Oracle HTTP Server Instances as a Different User (UNIX Only).

  3. Stop the instance if it is running by using any of the stop methods described in Stopping Oracle HTTP Server Instances.

  4. Start the instance by using any of the start-up methods described in Starting Oracle HTTP Server Instances.

Starting Oracle HTTP Server Instances as a Different User (UNIX Only)

On UNIX systems, the Oracle HTTP Server worker processes (the processes that accept connections and handle requests) may be configured to run as a different user id than the user id used to create the instance.

Follow the directions in Starting Oracle HTTP Server Instances on a Privileged Port (UNIX Only) and configure the User directive with the desired user id. The configured user id must be in the same group as the group that owns the instance directory. The Group directive must also be configured and set to the same group id used to create the instance.

Note:

  • The parent process and logging processes of the Oracle HTTP Server will run as root—these processes neither accept connections nor handle requests.

  • If Node Manager is configured to use the SSL listener, then ensure that other users have the appropriate permissions to access the SSL trust store used by NodeMmanager so that the startComponent.sh or nmConnect commands can run successfully as a different user.

    See Node Manager Overview in Administering Node Manager for Oracle WebLogic Server.

Stopping Oracle HTTP Server Instances

This section contains information on how to stop Oracle HTTP Server using Fusion Middleware Control and WLST. Be aware that other services might be impacted when Oracle HTTP Server is stopped.

This section includes the following topics:

Parent topic: Performing Basic Oracle HTTP Server Tasks

Stopping Oracle HTTP Server Instances Using Fusion Middleware Control

In Fusion Middleware Control, you can stop Oracle HTTP Server from the Oracle HTTP Server home page. Navigate to the Oracle HTTP Server home page and do one of the following:

  • From the Oracle HTTP Server home page:

    1. Select the server instance you want to stop.

    2. Select Control then Shut Down from the Oracle HTTP Server drop-down menu on the server instance home page.

  • From the Target Navigation tree:

    1. Right-click the Oracle HTTP Server component you want to stop.

    2. Select Control.

    3. Select Shut Down from the Control menu.

  • From the page header on the server instance home page, select Shut Down.

Stopping Oracle HTTP Server Instances Using WLST

You can stop Oracle HTTP Server by using WLST. From within the scripting tool, use one of the following commands:

Note:

  • Node Manager must be running for these commands to work. If it is down, you will receive an error message.

  • serverType is required for standalone domains. If it is not included, an error will be thrown referencing an inability to find startWebLogic

Domain Syntax Example

WebLogic

 
shutdown('serverName')
 
shutdown('ohs1')

Standalone

 
nmKill(serverName='serverName', serverType='type')Foot 1
 
nmKill(serverName='ohs1', serverType='OHS')

Footnote 1

nmKill() will also work in a WebLogic domain.

WARNING:

If you run shutdown() without specifying any parameters, WebLogic Server will terminate and exit WLST. Oracle HTTP Server will continue running. To recover, restart WebLogic Server, launch WLST, and reconnect to the AdminServer. Then re-run the shutdown with the Oracle HTTP Server instance name.

Stopping Oracle HTTP Server Instances from the Command Line

You can stop Oracle HTTP Server instances from the command line by invoking the stopComponent script from the host that contains the Administration Server.

  1. Enter the following command:
    $DOMAIN_HOME/bin/stopComponent.sh componentName

    For example:

    $DOMAIN_HOME/bin/stopComponent.sh ohs1

    This command invokes WLST and executes the nmKill() command. The stopComponent command will not function if Node Manager is not running.

  2. When prompted, enter your Node Manager password.

    If you started Oracle HTTP Server instance with the storeUserConfig option as described in Storing Your Node Manager Password, you will not be prompted.

    Once the server is stopped, the system will respond:

    Successfully killed server componentName...
Successfully disconnected from Node Manager...

Exiting WebLogic Scripting Tool.

Note:

You can also use this script to stop Oracle HTTP Server instances remotely. In that case, the scripts read the configuration to determine the location of the component. You must run this script from the same system as the Administration Server. See Remotely Administering Oracle HTTP Server.

About Using the WLST Commands

If you plan to use WLST, you should familiarize yourself with that tool. You should also be aware of the following restriction on WLST:

If you run a standalone version of Oracle HTTP Server, you must use the offline, or "agent", WLST commands. These commands are described in their appropriate context.

See Getting Started Using the Oracle WebLogic Scripting Tool (WLST) in Oracle® Fusion Middleware Administrator's Guide.

Parent topic: Performing Basic Oracle HTTP Server Tasks

Restarting Oracle HTTP Server Instances

Restarting Oracle HTTP Server causes the Apache parent process to advise its child processes to exit after their current request (or to exit immediately if they are not serving any requests). Upon restarting, the parent process re-reads its configuration files and reopens its log files. As each child process exits, the parent replaces it with a child process from the new generation of the configuration file, which begins serving new requests immediately.

The following sections contain information on how to restart Oracle HTTP Server using Fusion Middleware Control and WLST.

Parent topic: Performing Basic Oracle HTTP Server Tasks

Restarting Oracle HTTP Server Instances Using Fusion Middleware Control

In Fusion Middleware Control you restart Oracle HTTP Server from the Oracle HTTP Server home page. Navigate to the Oracle HTTP Server home page and do one of the following:

  • From the Oracle HTTP Server home page:

    1. Select the server instance you want to restart. Select Control.

    2. Click Start Up on the instance home page, or select Control then Restart from the Oracle HTTP Server drop-down menu.

  • From the Target Navigation tree:

    1. Right-click the Oracle HTTP Server instance you want to restart.

    2. Select Control.

    3. Select Restart from the Control menu.

Restarting Oracle HTTP Server Instances Using WLST

To restart Oracle HTTP Server by using WLST, use the softRestart() command. From within the scripting tool, enter one of the following commands:

Note:

  • For the WebLogic and the Standalone domains, Node Manager must be running (that is, state is RUNNING) for these commands to work. If it is down, you will receive an error message.

  • All parameters are required for standalone domains. If they are not included, an error will be thrown referencing an inability to find startWebLogic.

  • The nmSoftRestart command can also be used in WebLogic domains. To do this, you must first connect to Node Manager by using the nmConnect command.

Domain Syntax Example

WebLogic

 
softRestart('serverName')
 
softRestart('ohs1')

Standalone

 
nmSoftRestart(serverName='name', serverType='type')
 
nmSoftRestart(serverName='ohs1', serverType='OHS')
Restarting Oracle HTTP Server Instances from Command Line

To restart the Oracle HTTP Server instances from the command line, use the restartComponent script.

Run the following command:

$DOMAIN_HOME/bin/restartComponent.sh componentName

For example:

$DOMAIN_HOME/bin/restartComponent.sh ohs1

This command invokes WLST and executes the nmSoftRestart() command. The restartComponent command will not function if the Node Manager is not running. When prompted, enter your Node Manager password.

If you had started the instance with storeUserConfig option as described in Storing Your Node Manager Password, you will not be prompted for the Node Manager password.

Once the server is restarted, the system responds with the following message:

Successfully restarted server componentName...
Successfully disconnected from Node Manager...
Exiting WebLogic Scripting Tool.

Checking the Status of a Running Oracle HTTP Server Instance

This section contains information on how to check the status of a running Oracle HTTP Server instance. You can check this information from either Fusion Middleware Control installed as part of an Oracle Fusion Middleware infrastructure or by using WLST.

This section includes the following topics:

Parent topic: Performing Basic Oracle HTTP Server Tasks

Checking Server Status by Using Fusion Middleware Control

An up or down arrow in the top left corner of any Oracle HTTP Server page's header indicates whether the selected server instance is running. The up arrow indicates that the server instance, in this case, ohs_2, is running.

The down arrow indicates that the server instance, in this case, ohs_2, is not running.

Checking Server Status Using WLST

In a WebLogic Server Domain, if you used ohs_createInstance() to create the Oracle HTTP Server instance, its initial state (that is, before starting it) will be SHUTDOWN.

If you used the Configuration Wizard to generate the instance (both WebLogic Server Domain and standalone domain), its initial state (that is, before starting) will be UNKNOWN.

To check the status of a running Oracle HTTP Server instance by using WLST, from within the scripting tool, enter the following:

Note:

  • Node Manager must be running for these commands to work. If it is down, you will receive an error message. If Node Manager goes down in a WebLogic Server Domain, the state will be returned as UNKNOWN, regardless of the real state of the instance. Additionally state() does not inform you that it cannot connect to Node Manager.

  • Unlike other WLST commands, state() will not tell you when Node Manager is down so there is no way to distinguish an instance that truly is in state UNKNOWN as opposed to Node Manager simply being down.

  • All parameters are required for standalone domains. If they are not included, then an error will be thrown referencing an inability to find startWebLogic.

  • The nmServerStatus command can also be used in WebLogic domains. To do this, you must first connect to the Node Manager by using the nmConnect command.

Domain Syntax Example

WebLogic

 
state('serverName')
 
state('ohs1')

Standalone

 
nmServerStatus(serverName='name', serverType='type')
 
nmServerStatus(serverName='ohs1', serverType='OHS')

Note:

This command does not distinguish between non-existent components and real components in state UNKNOWN. Thus, if you enter a non-existent instance (for example, you made a typo), a state of UNKNOWN will be returned.

Deleting an Oracle HTTP Server Instance

You can delete an Oracle HTTP Server instance in both a WebLogic Server Domain and a standalone domain.

This section includes the following topics:

Parent topic: Performing Basic Oracle HTTP Server Tasks

Deleting an Oracle HTTP Server Instance in a WebLogic Server Domain

In a WebLogic Server Domain, you can use either the WLST custom command ohs_deleteInstance() or from Fusion Middleware Control installed as part of an Oracle Fusion Middleware infrastructure. The following topics describe these procedures.

Deleting an Instance Using WLST

If you are in a WebLogic Server Domain, you can delete an Oracle HTTP Server instance by using the WLST custom command ohs_deleteInstance(). When you use this command, the following happens:

  • The selected instance information is removed from config.xml.

  • All Oracle HTTP Server configuration directories and their contents are deleted; for example, OHS/instanceName and OHS/instances/instanceName. These paths refer to both the runtime and master copies of the configuration.

  • All logfiles associated with the deleted instance are deleted.

  • All state information for the deleted instance is removed.

Note:

You cannot delete an instance by using ohs_deleteInstance() if Node Manager is down.

To delete an instance using WLST:

  1. From the command line, launch WLST:

    Linux or UNIX: $ORACLE_HOME/oracle_common/common/bin/wlst.sh

    Windows: $ORACLE_HOME\oracle_common\common\bin\wlst.cmd

  2. Connect to WLST:

    • In a WebLogic Server Domain:

      > connect('loginID', 'password', '<adminHost>:<adminPort>')

      For example:

      > connect('weblogic', '<yourpassword>', 'abc03lll.myCo.com:7001')
  3. At the command prompt, enter:
    ohs_deleteInstance(instanceName='instanceName')

    For example, to delete an Oracle HTTP Server instance named ohs1 use the following command: 

    ohs_deleteInstance(instanceName='ohs1')

You cannot delete an Oracle HTTP Server instance in either an UNKNOWN or a RUNNING state.

Note:

For newly created Oracle HTTP Server instances in state UNKNOWN (for example, created with config wizard), one can start and stop the instance to move the state to SHUTDOWN. It can then be deleted successfully.

For instances in state RUNNING, first stop the instance to move it to state SHUTDOWN and then it can be deleted successfully.

Deleting an Instance Using Fusion Middleware Control

To delete an Oracle HTTP Server instance by using Fusion Middleware Control:

Note:

You cannot delete a running Oracle HTTP Server instance. If the instance is running, stop it, as described in Stopping Oracle HTTP Server Instances and then proceed with the following steps.

  1. Log in to Fusion Middleware Control. Navigate to the system component instance home page for the WebLogic Server Domain that contains the Oracle HTTP Server instance you want to delete.
  2. Open the WebLogic Server Domain menu and select Administration then Create/Delete OHS.
  3. In the OHS Instances page, select the instance you want to delete and click Delete.
  4. In the confirmation window, click Yes to complete the deletion.

    The OHS Instances page appears, with an information message indicating that the selected Oracle HTTP Server instance was deleted.

Deleting an Oracle HTTP Server Instance from a Standalone Domain

You can delete an Oracle HTTP Server instance in a standalone domain by using the Configuration Wizard if it is not the only instance in the domain. The Configuration Wizard always requires at least one Oracle HTTP Server instance in a standalone domain; you will not be able to delete the instance if it is the only one in the domain. To delete the only instance in a standalone domain, you should instead completely remove the entire domain directory.

Deleting Oracle HTTP Server instances by using the Configuration Wizard is actually only a partial deletion (and is inconsistent with the way WebLogic Server domain performs deletion by using ohs_deleteInstance(). See Deleting an Instance Using WLST). When you delete a standalone instance by using the Configuration Wizard, the following occurs:

  • Information on the specific instance is removed from config.xml, so this instance is no longer recognized as valid. When you launch the Configuration Wizard again for another update, the deleted instance will not appear.

  • The logs compiled for the deleted instance are left intact at: DOMAIN_HOME/servers/ohs1 (assuming your instance name was ohs1). If a new instance with the same name is subsequently created, it will inherit and continue logging to these files.

  • The deleted instance's configuration directories and their contents are not deleted; they remain intact at: DOMAIN_HOME/config/fmwconfig/components/OHS/instanceName and DOMAIN_HOME/config/fmwconfig/components/OHS/instances/instanceName. The only change in both directories is that the following files are renamed: httpd.conf becomes httpd.conf.bak; ssl.conf becomes ssl.conf.bak; and admin.conf becomes admin.conf.bak. This prevents the instance from being started. (If you create a new instance with the same name as the instance you deleted, this information will be overwritten, but the *.bak files will remain).

  • The deleted instance's state information is left intact at DOMAIN_HOME/system_components/. If a new instance of the same name is subsequently created, it will inherit the state of the old instance. Instead of starting in UNKNOWN state, it could appear as SHUTDOWN or even FAILED_NOT_RESTARTABLE.

To delete an Oracle HTTP Server instance in a standalone domain, do the following:

  1. Shutdown all running instances (see Stopping Oracle HTTP Server Instances). Be aware the Configuration Wizard will not check the state of the Oracle HTTP Server instance so you will need to verify that all instances are indeed stopped before deletion.

  2. If it is running, shut down Node Manager.

  3. Launch the Configuration Wizard (see Installing and Configuring Oracle HTTP Server) and do the following:

    1. Select Update an existing domain and select the path to the domain.

    2. Skip both the Templates screen and the JDK Selection screen by clicking Next on each.

    3. On the System Components screen, select the instance you want to delete and click Delete.

      The selected instance is deleted.

    4. Click Next, and, on the OHS Server screen, click Next again.

    5. On the Configuration Summary screen, verify that the selected instance has been deleted and click Update.

    6. On the Success screen, click Finish.

Changing the Default Node Manager Port Number

You can change the default value of the Node Manager port by using either WLST or the Oracle WebLogic Server Administration console.

This section includes the following topics:

Parent topic: Performing Basic Oracle HTTP Server Tasks

Changing the Default Node Manager Port Using WLST

To change the default Node Manager port number using WLST, use the custom command readDomain to open the domain. Navigate to the directory containing Node Manager for the machine. Set the ListenPort property, then update the domain. 

...
readDomain('DOMAIN_HOME')
cd('/Machines/Machine_Name/NodeManager/Node_Manager_Name')
set('ListenPort',9090)
updateDomain()
closeDomain()
...

In this example, DOMAIN_HOME represents the root directory of the domain. Machines and NodeManager are directories. The Node_Manager_Name is the name of Node Manager belonging to the Machine_Name machine. The default Node Manager name is localmachine. The default Machine_Name is also localmachine. The ListenPort value is set to 9090.

Changing the Default Node Manager Port Using Oracle WebLogic Server Administration Console

Follow these steps to change the default Node Manager port number using Oracle WebLogic Server Administration Console.

  1. Manually edit the DOMAIN_HOME/nodemanager/nodemanager.properties file to change the value of the ListenPort property.
  2. In the WebLogic Server Administration Console, change the configuration of the machine associated with Node Manager, to point it to the new port number.

    From the left pane of the Console, expand Environment and then select Machines. Select the machine whose configuration you want to edit. Select the Configuration tab, then the Node Manager tab. Change the Listen Port to the port updated in nodemanager.properties file. Click Save.

Updating the Node Manager Username and Password in a Standalone Domain

You can update username and password of the Node Manager in a standalone domain using WLST commands:

  1. Launch the WebLogic Scripting Tool (WLST) by running the following command from the location MW_HOME/oracle_common/common/bin:
    UNIX: ./wlst.sh
    Windows: wlst.cmd
  2. Execute the following WLST commands:
    1. readDomain('$DOMAIN_HOME')
    2. cd('SecurityConfiguration/$DOMAIN_NAME')
    3. set('NodeManagerUsername','new_NodeManager_Username')
    4. set('NodeManagerPasswordEncrypted','new_NodeManager_password')
    5. updateDomain()
    6. closeDomain()

If the Node Manager username and password have been saved using storeConfig option with startComponent, then delete the following after changing the Node Manager credentials and before you restart OHS:

  • user_home/.wlst/nm-key-domain_name.props
  • user_home/.wlst/nm-cfg-domain_name.props

Parent topic: Performing Basic Oracle HTTP Server Tasks

Remotely Administering Oracle HTTP Server

You can remotely manage an Oracle HTTP Server instance running in a standalone environment from a collocated Oracle HTTP Server implementation running on a separate machine. Use WLST or Fusion Middleware Control to start, stop, and configure the server from the remote machine.

This section provides information about how to set up Oracle HTTP Server to run remotely.

Parent topic: Running Oracle HTTP Server

Setting Up a Remote Environment

The following instructions describe how to set up a remote environment, which will enable you to run Oracle HTTP Server installed on one machine from an installation on another. This section contains the following information:

Parent topic: Remotely Administering Oracle HTTP Server

Host Requirements for a Remote Environment

To remotely manage Oracle HTTP Server, you must have separate hosts installed on separate machines:

  • A collocated installation (for this example, this installation will be called host1).

  • A standalone installation (host2). The path to standalone MW_HOME on host2 must be the same as the path to the collocated MW_HOME on host1. For example:
    /scratch/user/work
Task 1: Set Up an Expanded Domain on host1

The following steps describe how to set up an expanded domain and link it to a database on the collocated version of Oracle HTTP Server (host1):

  1. Using the Repository Configuration Utility (RCU), set up and install a database for the expanded domain.See Creating Schemas with the Repository Creation Utility.
  2. Launch the Configuration Wizard and create an expanded domain. Use the values specified in Table 4-1.

    Table 4-1 Setting Up an Expanded Domain

    For... Select or Enter...

    Create Domain

    Create a new domain and specify its path (for example, MW_HOME/user_projects/domains/ohs1_domain).

    Templates

    Oracle HTTP Server (Collocated)

    Application Locations

    The default.

    Administrator Account

    A username and password.

    Database Configuration Type

    The RCU data. Then, click Get RCU Configuration and then Next.

    Optional Configuration

    The following items:

    • Administration Server

    • Node Manager

    • System Components

    • Deployment and Services

    Administration Server

    The listen address (All Local Addresses or the valid name or address for host1) and port.

    Node Manager

    Per Domain and specify the NodeManager credentials.

    System Components

    Add and set the fields, using OHS as the Component Type (for example, use a System Component value of ohs1).

    OHS Server

    The listen addresses and ports or use the defaults.

    Machines

    Add. This will add a machine to the domain (for example, ohs1_Machine) and the Node Manager listen and port values. You must specify a listen address for host2 that is accessible from host1, such the valid name or address for host2 (do not use localhost or All Local Addresses).

    Assign System Components

    The OHS component (for example, ohs1) then use the right arrow to assign the component to the machine (ohs1_machine, for example).

    Configuration Summary

    Create (the OPSS steps may take some minutes).

Task 2: Pack the Domain on host1

On host1, use the pack command to pack the domain. The pack command creates a template archive (.jar) file that contains a snapshot of either an entire domain or a subset of a domain.

On Unix, run the following command:

MW_HOME/oracle_common/common/bin/pack.sh -domain=path_to_domain -template=path_to_template -template_name=name -managed=true

For example:

MW_HOME/oracle_common/common/bin/pack.sh -domain=MW_HOME/user_projects/domains/ohs1_domain -template=/tmp/ohs1_tmplt.jar -template_name=ohs1 -managed=true
Task 3: Unpack the Domain on host2

The unpack command creates a full domain or a subset of a domain used for a Managed Server domain directory on a remote machine. Use the following steps to unpack the domain you packed on host1 in Task 2: Pack the Domain on host1, on host2.

  1. Copy the template file created in Task 2: Pack the Domain on host1 from host1 to host2.
  2. Run the unpack command on Unix to unpack the domain:
    MW_HOME/oracle_common/common/bin/unpack.sh -domain=path_to_domain -template=path_to_template

    For example:

    MW_HOME/oracle_common/common/bin/unpack.sh -domain=MW_HOME/user_projects/domains/ohs1_domain -template=/tmp/ohs1_tmplt.jar
Task 4: Run Oracle HTTP Server Remotely

Once you have unpacked the domain created on host1 onto host2, you can use the same set of WLST commands and Fusion Middleware Control tools you would in a collocated environment to start, stop, restart, and configure the component.

To run an Oracle HTTP Server remotely, do the following:

  1. Start the WebLogic Administration Server on host1:
    <MW_HOME>/user_projects/domains/ohs1_domain/bin/startWebLogic.sh &
  2. Start Node Manager on host2:
    <MW_HOME>/user_projects/domains/ohs1_domain/bin/startNodeManager.sh &

You can now run the Oracle HTTP Server instance on host2 from the collocated implementation on host1. You can use any of the WLST commands or any of the Fusion Middleware Control tools. For example, to connect host2 to Node Manager and start the server ohs1, from host1 enter: 

<MW_HOME>/ohs/common/bin/wlst.sh
nmConnect('weblogic', '<password>', '<nm-host>', '<nm-port>', '<domain-name>', '<domain-directory>','ssl') 
nmStart(serverName='ohs1', serverType='OHS')

See Performing Basic Oracle HTTP Server Tasks for information on starting, stopping, restarting, and configuring Oracle HTTP Server components.

Configuring SSL for Admin Port

Admin port is used internally by Oracle HTTP Server (OHS) to communicate with the OHS plugin for Node Manager. The OHS plugin for Node Manager has been enhanced to use SSL for its communication with the Node Manager.

The configuration steps described in the following topics are necessary to set up SSL communication between the OHS admin host (SSL server) and the OHS plugin for Node Manager (SSL client):

Parent topic: Running Oracle HTTP Server

Performing Server-Side Configuration

To complete the server-side configuration, you must create a wallet and enable SSL for Oracle HTTP Server admin host by modifying the admin.conf file present in the staging directory.

To do this, refer to the following topics:

  1. Creating a Wallet
  2. Enabling SSL for Oracle HTTP Server Admin Host

For information about modifying the admin.conf file, see Modifying an Oracle HTTP Server Configuration File.

Parent topic: Configuring SSL for Admin Port

Creating a Wallet

Create a wallet that contains a certificate signed by a trusted CA.

Consider the requirements for ensuring the success of the host-name verification step of the SSL handshake while choosing the Common Name attribute of the certificate’s Distinguished Name(DN). See Ensuring that the Host Name Verification Succeeds.

To create a wallet, refer to the following topics depending on your installation type:

Creating a Wallet for a Standalone Installation

To create a wallet for a standalone installation, use the KEYTOOL utility to create a keystore, generate a Certificate Signing Request (CSR), import the required certificates to the keystore, convert this keystore to a wallet using the ORAPKI utility, and then configure Oracle HTTP Server admin host to use this wallet.

To do this, complete the following steps:

  1. Set the following environment variables:

    On UNIX:

    export ORACLE_HOME=absolute_path_to_ORACLE_HOME
export PATH=$ORACLE_HOME/oracle_common/bin:$PATH
export JAVA_HOME=absolute_path_to_JDK8

    On Windows:

    set ORACLE_HOME=absolute_path_to_ORACLE_HOME
set PATH=%ORACLE_HOME%\oracle_common\bin:%PATH%
set JAVA_HOME=absolute_path_to_JDK8

  2. Set up a working directory and change the directory to the same:

    mkdir walletkey
cd walletkey

  3. Create a keystore and a private key:

    keytool -genkey -alias ca_cert -keyalg RSA -keysize 2048 -sigalg SHA256withRSA -dname "CN=hostname.domainname,O=My Company Corporation,L=Denver,ST=CO,C=US" -keypass keypass_password -keystore keystore.jks -storepass storepass_password

    In this command:

    • The alias ca_cert is what will be established. You can choose a different name.
    • keystore.jks is the name you choose for the new keystore.
    • keypass_password and storepass_password are the password you specify for keypass and storepass respectively.

  4. Generate a Certificate Signing Request (CSR) and send it to your Certificate Authority (CA) before you proceed (otherwise, use a self-signed):

    keytool -certreq -v -alias ca_cert -file server.csr -sigalg SHA256withRSA -keypass keypass_password -storepass storepass_password -keystore keystore.jks

    In this command:

    • ca_cert is the alias you specified in the previous step.
    • server.csr is what you give the CA.
    • keystore.jks is the keystore.

  5. Import the root trust certificate into the keystore:

    keytool -import -v -noprompt -trustcacerts -alias root -file root.crt -keystore keystore.jks

    In this command:

    • The alias root is the name you choose for the intermediate CA trust certificate.
    • root.crt is the CA's root trust certificate.
    • keystore.jks is the keystore.

  6. If supplied from CA, import the Intermediate trust certificate into a the keystore, and choose an alias:

    keytool -import -v -noprompt -trustcacerts -alias intermediate -file intermediate.crt -keystore keystore.jks

    In this command:

    • The alias intermediate is the name you choose for the intermediate CA trust certificate.
    • intermediate.crt is the CA's intermediate trust certificate.
    • keystore.jks is the keystore.

  7. Import the signed server certificate into the keystore:

    keytool -import -v -alias ca_cert -file server.crt -keystore keystore.jks

    In this command:

    • The alias ca_cert is the name you had chosen for server certificate.
    • server.crt is the signed server certificate that you normally get from the CSR.
    • keystore.jks is the keystore.

  8. Convert the keystore to the wallet:

    orapki wallet create -wallet ./wallet -auto_login_only
orapki wallet jks_to_pkcs12 -wallet ./wallet -keystore ./keystore.jks -jkspwd jks_password

  9. Configure the wallet in the Oracle HTTP Server admin.conf file. To make it simple and consistent, use a generic central location as shown in the following example. Ensure that the location is owned by the same Oracle user.

    Example of admin.conf file: 

    
<VirtualHost AdminHostIP:AdminPort>
<IfModule ossl_module>
 ...
 SSLWallet "/usr/oracle/ohs/wallets"
 ...
</IfModule>
</VirtualHost>

Creating a Wallet for a Collocated Installation

For a collocated installation, create a wallet for Oracle HTTP Server admin host via Fusion Middleware Control and configure the Oracle HTTP Server admin host to use this wallet.

  1. Log in to the Fusion Middleware Control using the WebLogic username and password:

    http://host.domain:port/em

  2. Start the relevant OHS component (for example, ohs1) via Fusion Middleware Control.

    Note:

    A keystore is uniquely identified by an application stripe and a keystore within that stripe. Keys and certificates are created in keystores within stripes. Stripe names within the security store are unique in the security store, and the keystore names within a stripe are unique in the stripe. For example, (stripe1,keystoreA), (stripe1,keystoreB), and (stripe2,keystoreA) refer to three distinct keystores. Applications can create more than one keystore within the application stripe.

  3. Create a Stripe for Oracle HTTP Server:

    1. Navigate to the weblogic domain, go to Security, and click Keystore.
    2. Click Create Stripe.
    3. Create new stripe by name OHS. Note that the name is case sensitive.

  4. Create a Keystore for OHS instance:

    1. Click on the ohs instance.
    2. Navigate to OracleHTTPServer, go to Security, and click Keystore.
    3. Click Create Keystore and then click Create it as a Policy.
    4. Enter the keystore name. For example, Test. A new keystore is created with the name instancename_Test (for example, ohs1_Test).

  5. Generate Keypair:

    1. Select the new keystore (ohs1_Test) and click Manage.
    2. Click Generate Keypair.
    3. Enter the required details and click OK.

  6. Generate CSR:

    1. Select the new Keypair generated.
    2. Click Generate CSR. The page with the following information is displayed:
      Certificate signing request with Alias: ohs_cert is exported successfully. To export it to a
      file, click "Export CSR". You can send this file to a CA or you can cut and paste the entire
      text in the box from BEGIN NEW CERTIFICATE REQUEST to END NEW CERTIFICATE REQUEST. Once you
      get your certificate back from CA you can continue with import.
    3. Click Export CSR and save the file.

      Ensure that the Lock and Edit is used so that the changes are committed. If the keystore is not saved, you cannot import the new certificate. Therefore, before requesting the certificate, exit the browser and go back to verify that the keystore is saved.

  7. Obtain CA signed certificate by sending CSR to any CA and obtaining the certificates.

  8. Import the Trusted Certificate:

    1. Navigate to OracleHTTPServer, go to Security, and click Keystore.
    2. Select the keystore from which the CSR was generated and click Manage.
    3. Click Import.
    4. In the Certificate Type, select Trusted Certificate and either paste the contents of the root CA certificate rootca.crt, or select the file and click OK.
    5. Repeat the above steps for any other Trusted CA Certificates in the chain.

  9. Import the Trusted Certificate to weblogic domain. Also import the root CA certificate and any other Trusted CA Certificates to weblogic system stripe under trust keystore:

    1. Navigate to the weblogic domain, go to Security, and click Keystore.
    2. Expand system stripe, select trust keystore, and click Manage.
    3. Click Import.
    4. In the Certificate Type, select Trusted Certificate and either paste the contents of the root CA certificate rootca.crt, or select the file and click OK.
    5. Repeat the above steps for any other Trusted CA Certificates in the chain.

  10. Import the User Certificate:

    1. Navigate to OracleHTTPServer, go to Security, and click Keystore.
    2. Select the keystore from which the CSR was generated, and click Manage.
    3. Click Import.
    4. In the Certificate Type, select Certificate and either paste the contents of server.crt, or select the file and click OK.

  11. Export Key store to wallet:

    1. Navigate to OracleHTTPServer, go to Security, and click Keystore.
    2. Select the keystore from which the CSR was generated, and click Manage.
    3. Click Export Keystore to Wallet. An Auto-Login Only Wallet is created in keystore directory of OHS instance.

    Note:

    Before you export the keystore to a wallet, ensure that you click Lock and Edit and then click Activate Changes.

  12. Configure the wallet in the Oracle HTTP Server by editing the admin.conf file to point to the newly created wallet.

    Example of admin.conf file: 

    <VirtualHost AdminHostIP:AdminPort>
<IfModule ossl_module>
 ...
 SSLWallet "/usr/oracle/ohs/wallets"
 ...
</IfModule>
</VirtualHost>

    Note:

    admin.conf file cannot be edited via Fusion Middleware Control. To manually edit it, see Modifying an Oracle HTTP Server Configuration File.
Enabling SSL for Oracle HTTP Server Admin Host

Enable SSL for the admin host by configuring the following mod_ossl directives in a <IfModule ossl_module> block.

By default, admin.conf file includes the following configuration settings.

Sample configuration:

<VirtualHost 127.0.0.1:9991>
<IfModule ossl_module>
 SSLEngine on
 SSLProtocol TLSv1.2
 SSLCipherSuites TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,SSL_RSA_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_AES_256_CBC_SHA 
 SSLWallet “<wallet location>”
</IfModule>
</VirtualHost>

Ensuring that the Host Name Verification Succeeds

Host name verification happens as part of the SSL handshake between the Node Manager and the Oracle HTTP Server (OHS) admin host.

Host name verification succeeds if the host name in the admin host URL to which the Node Manager connects, matches the host name in the digital certificate that the OHS admin host sends back as part of the SSL connection.

To ensure that this verification step succeeds, you must configure the host name for Oracle HTTP Server admin host correctly as described in the following sections:

ServerName Directive Configuration

Use the ServerName directive to configure the host name for the Oracle HTTP Server admin host. The host name configured must match the Common Name attribute of the SSL certificate's Distinguished Names or match the subjectAltName extension. Place the ServerName directive within the <VirtualHost> block in the admin.conf file.

Note:

If ServerName directive is not configured when SSL is enabled for the communication between Node Manager and the OHS admin host, OHS fails to start with the following message:

ServerName directive is not configured in admin.conf of <ohs_instance>

Once the host name is configured, changes to the Listen directive configuration may be required, as Listen directive and host name configurations are linked.

Listen Directive Configuration

Choose an IP address and port for the admin host and configure the Listen directive with this. The host name configured using the ServerName directive must map to the IP address configured in the Listen directive of the admin.conf file. This is to avoid the host name resolution errors during the communication between Node Manager and OHS admin host. The IP address used for the Listen directive must match the one used with the <VirtualHost> directive.

Note:

Use nslookup to ensure that the IP address used in the Listen directive is correctly mapped to the host name of the admin host.

If the Listen directive is configured to listen on all available interfaces (that is, Listen <port>), instead of a specific IP address (that is, Listen <ipaddress>:<port>, OHS fails to start with the following message: 

HostName/IP address is not configured for Listen directive in admin.conf of <ohs_instance_name>

After you configure SSL on the server-side, the admin.conf configuration looks like the following sample: 

#[Listen] OHS_PROXY_PORT
Listen <IP>:<PORT>
#[VirtualHost] OHS_PROXY_VH
<VirtualHost <IP>:<PORT>>

// Ensure <HOSTNAME> resolves to <IP>
ServerName <HOSTNAME>
<Location /dms/>
  SetHandler dms-handler
  Require all granted
</Location>
CustomLog "||${PRODUCT_HOME}/bin/odl_rotatelogs 
${ORACLE_INSTANCE}/servers/${COMPONENT_NAME}/logs/admin_log 43200" common
<IfModule ossl_module>
  SSLEngine on
  SSLProtocol TLSv1.2
  SSLCipherSuite 
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,SSL_RSA_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_AES_256_CBC_SHA

// Ensure CN attribute of the certificate’s DN matches <HOSTNAME>
  SSLWallet “<WALLET LOCATION>”
 </IfModule>
</VirtualHost>

Note:

In the above sample, <IP>, <PORT>, <HOSTNAME>, and <WALLET LOCATION> are the details of your environment.

Parent topic: Configuring SSL for Admin Port

Performing Client-Side Configuration

On the client-side, you must configure trust for the Node Manager.

Ensure that Node Manager is able to trust the certificate configured for the Oracle HTTP Server (OHS) admin host. This is done by exporting the certificate of root CA that signed the user certificate present in the OHS admin host's wallet and importing the same into the Node Manager's wallet for the instance as a trusted certificate. The Oracle HTTP Server plugin for Node Manager is enhanced to maintain a per-instance wallet that contains the trusted certificates for the OHS admin host of that instance.

To configure the Node Manager’s wallet for an instance, add the nm-wallet property to the ohs.plugins.nodemanager.properties file located at $DOMAIN_HOME/config/fmwconfig/components/COMPONENT_TYPE/COMPONENT_NAME, and set it to the absolute path to the wallet that contains the trusted certificates.

To set up trust for the Node Manager:

  1. Export the root CA certificate that signed the user certificate present in the Oracle HTTP Server admin host's wallet:
    $orapki wallet export -wallet path_to_server_wallet -dn "DN for root CA certificate" -cert root_CA.crt
  2. Create a wallet for the Node Manager :
    $orapki wallet create -wallet /test/my_nm_wallet -auto_login_only
  3. Import the certificate for the root CA into my_nm_wallet as a trusted certificate:
    $orapki wallet add -wallet /test/my_nm_wallet -trusted_cert -cert root_CA.crt -auto_login_only

Configure the nm-wallet property in the ohs.plugins.nodemanager.properties file to point to the Node Manager's wallet:

  1. Open the file ohs.plugins.nodemanager.properties located at $DOMAIN_HOME/config/fmwconfig/components/COMPONENT_TYPE/COMPONENT_NAME in a text editor.
  2. Add nm-wallet=/test/my_nm_wallet to the end of the file.

Note:

You cannot edit the ohs.plugins.nodemanager.properties file using Fusion Middleware Control or WLST. To edit it manually, see Modifying an Oracle HTTP Server Configuration File.

Parent topic: Configuring SSL for Admin Port